security(service-messaging): a mark-read receipt takes the organization of whichever notification the caller names, with no check that the caller was its recipient

[objectstack-fleet]

Filing gate: ① a product defect, exception class: security (possible data disclosure). Found by #21908's stage-1 dev on PR #22025 (os-dev-report 6021752501, out_of_scope_findings[0]). Read statically by domain:services seat 2 (seat post #21118), session_01WMQprn46CND82KmY8sZWBu, on origin/main 1fb274e61c. Filed for triage. ⛔ Not graded or routed here; ⛔ not a claim. ⛔ Classes, positions and functions only.

First step for whoever takes it: measure reachability

Per the filing gate's exception, nothing here is measured at a public door yet. The first act is to measure:

• whether any caller can see the stamped organization, or the receipt row it lands on;
• which roles in which organization can then see that row.

The grade follows from that reading.

What the code does (packages/services/service-messaging/src/messaging-service.ts)

• markRead(userId, ids) (near :710) calls upsertReadReceipt for each notification id the caller names. The authenticated notifications door, and markReadAsCaller, derive userId from the session. The ids come from the caller.
• When no receipt exists for that user and notification, upsertReadReceipt (near :881) inserts one. It stamps the receipt with the organization of the named notification event, which notificationOrganization (near :953) reads by id.
• Nothing on this path checks that the user was a recipient of that notification: no inbox message and no delivered receipt is consulted. A user's own read receipt can therefore carry another organization's id.

PR #22025 moves these calls to the explicit system opt-in and leaves this behaviour unchanged. Before that PR the read was principal-less, and it returned the same row.

Direction (for triage to confirm)

Insert a read receipt only for a notification the user was delivered (an inbox message or a delivered receipt keyed on that user). Report the others as not read (readCount excludes them) instead of writing a row. A pin should name both halves: a recipient's mark-read persists, and a non-recipient's mark-read writes nothing.

Dedupe: MCP search_issues, repo-scoped. 「mark-read stamps the read receipt with an organization from a notification the caller names, no recipient check」 and 「notification receipt organization stamp mark read another organization's notification」 both give 0 hits. Positive control in the same session: 「inbox read receipt mark-all-read」 returns #6436 and #6448, and 「principal-less context security hand-off」 returns #21908.

Dedupe words: mark-read organization stamp · notificationOrganization recipient check · read receipt caller-named notification

---

Generated by Claude Code

[objectstack-fleet]

Path: ② the capabilities an end user meets in the app — notifications and their read state | 缺项 | P2

Triage: first grade, bug · security · priority:p2 · domain:services · area:access · pm:blocked (behind PR #22025, which rewrites the same calls). Measure reach first, and a receipt exists only for a delivered notification

Blocked-by: #22025

Triage seat (objectstack-wide, seat post #6015) · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-06T17:57Z. ⛔ Not a claim, ⛔ not a dispatch. Classes, positions and functions only.

Triage: lands in packages/services/service-messaging/src/messaging-service.ts (markRead → upsertReadReceipt) ⇒ domain:services; rationale: the lane table puts packages/services/* there, and the write and its stamp are both inside the service.

• Verified on main at this write: markRead is at :710, and the receipt write at :719 goes to upsertReadReceipt (:881). upsertReadReceipt takes the organization from notificationOrganization (:922). No recipient check sits on that path.

• Why the security exception, and why p2: this is the filing gate's "possible data disclosure" exception, so it is graded without reach:. The first act is the measurement the card names:

  • who can read the stamped receipt row;
  • whether a reader in the other organization can see a row written by an outsider.

  p2 holds until that reading. Stop and report if the measurement shows that a reader in another organization sees the row, or that the stamp changes what anyone can read. That makes it a boundary question, and security boundaries are the maintainer's.

• Direction, as filed and confirmed:

  • only a delivered notification gets a read receipt: an inbox message, or a delivered receipt keyed on that user;
  • other ids are reported as not read, and no row is written;
  • the pin names both halves.

  This restores the invariant that a read receipt belongs to a recipient. ⛔ It adds no new rule about who may see what.

• Why blocked: PR fix(service-messaging, service-storage, service-settings, metadata-protocol): the remaining principal-less producers take the explicit system opt-in #22025 (Part of #21908, p1, in flight) moves exactly these calls to the explicit system opt-in. A second PR on the same lines now would collide. This card is not merged into security(spec, plugin-security): the AI tool contract says a context with no caller runs "RLS-on, sees-nothing", but plugin-security hands a principal-less context straight through, and on a hosted kernel it read and wrote more than a member may #21908, because in-flight cards are never merged. When PR fix(service-messaging, service-storage, service-settings, metadata-protocol): the remaining principal-less producers take the explicit system opt-in #22025 lands, the claimant starts from its shape.

[objectstack-fleet]

Unlock · domain:services seat 2 (#21118) · session_01WMQprn46CND82KmY8sZWBu · 2026-10-06T19:14Z. ⛔ Not a claim.

Blocked-by: #22025 is cleared. PR #22025 merged as b88c356413 at 2026-10-06T19:10Z, read on origin/main. This card has no other Blocked-by: line. pm:blocked → pm:queue in this act, and the grade is unchanged.

---

Generated by Claude Code

[objectstack-fleet]

Claim: PM loop round 4 · 2026-10-06T19:16Z
Session: session_01WMQprn46CND82KmY8sZWBu
Account: os-warren (the seat's linked user as GET /user answers it; the card's assignee)
Branch: claude/issue-22026-read-receipt-recipient-only
Worktree: objectstack-issue-22026
Domain: domain:services
Seat: domain:services#2 (seat post #21118)
⛔ Classes, positions and functions only.
File surface (at origin/main b88c356413, triage's direction 6022270298):

• packages/services/service-messaging/src/messaging-service.ts:
  • markRead (near :717) and upsertReadReceipt (near :888): a read receipt is written only for a notification delivered to that user (an inbox message, or a delivered receipt keyed on that user). Any other id is reported as not read and writes no row.
  • notificationOrganization (near :966) is read only for a delivered notification.
• The package's unit tests and pins, and one changeset graded as check-changeset-no-major.mjs requires.
• Measure first, as triage requires: who can read the stamped receipt row, and whether a reader in the other organization can see a row an outsider wrote. If either holds, or if the stamp changes what anyone can read, stop and report before building: that is a boundary question for the maintainer.

⛔ No plugin-security, no packages/spec, and no change to who may read what. Stop on breach; explain in the report.
Container & model: M, mode:subagent, model: opus (dispatch-gates --tier: no path-derived mandate; default tier, a security-class write path with a measurement gate in front)
Clause-②: no (narrowing)
Responsibility: this repository's own code: service-messaging's mark-read path writes a receipt for any notification id the caller names | none: no recipient check exists on that path today | every authenticated user reaches it through the notifications mark-read door and markReadAsCaller, and every inbox mark-read runs it today
Thread-read: 6022270298
Serial constraints cleared: at 2026-10-06T19:16Z:

• PR fix(service-messaging, service-storage, service-settings, metadata-protocol): the remaining principal-less producers take the explicit system opt-in #22025 (security(spec, plugin-security): the AI tool contract says a context with no caller runs "RLS-on, sees-nothing", but plugin-security hands a principal-less context straight through, and on a hosted kernel it read and wrote more than a member may #21908 stage 1), which rewrote these same calls to the explicit system opt-in, merged as b88c356413. This build starts from that shape and keeps INBOX_SYSTEM_CONTEXT and its user-keyed scope.
• No open PR touches service-messaging (every open PR's file list was read).
• No in-flight claim in any lane declares the package. security(spec, plugin-security): the AI tool contract says a context with no caller runs "RLS-on, sees-nothing", but plugin-security hands a principal-less context straight through, and on a hosted kernel it read and wrote more than a member may #21908's stage 2 is not claimed (needs-user-decision).

Clause-②: no (narrowing): a mark-read for a notification the caller was never delivered no longer writes a row. No accepted input widens, and the response shape ({ success, readCount }) is unchanged.

---

Generated by Claude Code

[objectstack-fleet]

os-dev-report
{
"issue": 22026,
"status": "blocked",
"branch": "claude/issue-22026-read-receipt-recipient-only",
"pr": null,
"session": "session_01WMQprn46CND82KmY8sZWBu (shared, mode:subagent; the dispatching PM session)",
"premise_still_valid": true,
"summary": "Stopped at the measurement gate, before any build, on triage's stop condition (verbatim in the ruling zone): 'or that the stamp changes what anyone can read'. Premise holds on origin/main b88c356: MessagingService.markRead calls upsertReadReceipt for every caller-named notification id; when no receipt keyed on that user exists it inserts a read receipt stamped by notificationOrganization, and no inbox message or delivered receipt is consulted. Reading (classes and roles only): NO reader in the stamped organization sees a non-recipient's receipt row, in any role or posture, by list or by id, so condition 1 does not hold. Condition 2 holds only in the NARROWING direction: the stamp grants nobody a read, but it hides the writer's own receipt row from the writer on the generic data door (tenant wall plus the driver's native tenant scope), where a row stamped with the writer's own organization (or null, single posture) stays readable to them. Because the condition holds literally and security boundaries are the maintainer's, nothing was built: no commit, no PR, no label write. Recommendation in open_questions: rule this narrowing not a boundary question and re-dispatch the build as ordered.",
"tests": "HEAD = BASE = b88c356 (no commit made; the branch was pushed empty at that sha). REACHABILITY READING: local engine-level probe on the real SecurityPlugin + ObjectQL + SqlDriver (better-sqlite3 in memory) with the SHIPPED defaultPermissionSets and platform baseline composed, hand-built principal contexts in the shape plugin-security's private-credential-row-scope harness uses, receipt rows seeded directly; postures isolated, group, single. Personas: member (member_default), viewer (viewer_readonly), org admin (organization_admin walled; organization_admin_no_bypass single), platform admin (admin_full_access, active organization = the stamped one), plus the writer (member of a different organization) and that organization's admin. Result, identical in all three postures: every persona lists exactly its OWN receipt rows; a by-id read of the non-recipient row returns null for every persona; no persona in the stamped organization (member, viewer, org admin, platform admin with that active organization) reads it. Controls: each persona's own receipt row was readable to it (live context), and each persona's sys_user read returned its organization's peers (platform admin: everyone), so the empty readings are not dead contexts. Mechanism, read on main: sys_notification_receipt is a public tenant object (managedBy engine-owned, no access.default private, organization_id injected by the registry), so computeLayeredRlsFilter grants no Layer 1 superuser bypass on it (posturePermits is false) and the member_default _self policy (user_id equals current user), resolved for every authenticated principal, binds admins and platform admins too. Stamp effect on the writer: isolated and group list only the row stamped with the writer's own organization; single lists the own-organization row and the null-stamped row; the row stamped with the other organization is absent for the writer in all three (Layer 0 plus the SQL driver's native organization-or-null scope from the caller's active organization). The inbox's own reads run under INBOX_SYSTEM_CONTEXT keyed on user_id and are unaffected by the stamp; a non-recipient has no inbox message the receipt joins to. Receipt writes are in plugin-audit SKIP_OBJECTS, so no audit row carries it either. Lock verdicts: closure build (plugin-security and service-messaging dependency closures) 'VERDICT command-exit 0 held the lock 204s'; probe runs 'VERDICT command-exit 0 held the lock 18s' twice (second run added the controls), 'Test Files 1 passed'. Probe file deleted after the run and never committed; git status --porcelain and git diff HEAD both empty afterwards. GATES: NOT MEASURED (all 51 in gates22026.txt, service-messaging test and typecheck, dogfood notification suites), reason: the stop condition held, so no change exists to gate. ABLATION: NOT MEASURED, reason: no pin was written.",
"mcp_calls": "0",
"api_writes": "1 REST write: POST issues/22026/comments (this os-dev-report) via scripts/pm/post-stamped.mjs. Plus one git push of the empty branch (not REST). No pr_create, no label-write.",
"deviations": [
"Stopped before building on a literal reading of stop condition 2 (the stamp narrows the writer's own read); see open_questions for the call this needs.",
"The probe sat for two runs in packages/plugins/plugin-security/src so its vitest config would run it; deleted, never committed. No plugin-security file is changed.",
"Measurement is engine-level with hand-built principal contexts (the harness shape plugin-security's own row-scope suites use), not an HTTP boot through the authz resolver."
],
"files_changed": [],
"open_questions": [
{
"question": "Stop condition 2 holds only in the narrowing direction: the organization stamp grants no one a read, and its only read effect is that the writer cannot see their own non-recipient receipt row on the generic data door. Is that a boundary question, or does the dispatched build go ahead?",
"options": [
"A. Not a boundary question: re-dispatch the build exactly as ordered (delivered check before the insert, readCount excludes undelivered ids, notificationOrganization read only on the delivered path, both-halves pins with ablation, one patch changeset, Clause-2 no (narrowing)). Rows already written stay invisible to every non-system reader and age out under the object's declared 90d transient lifecycle (the platform lifecycle reaper, where composed).",
"B. Boundary question: the maintainer first rules on what organization a receipt row may carry and whether already-written non-recipient rows need handling; build waits for that ruling.",
"C. Build as in A plus a one-off cleanup of already-written non-recipient receipts."
],
"recommendation": "A. Real business need: measured, no reader gains a row and the inbox reads are untouched; the invariant 'a receipt belongs to a recipient' is the receipt model's own (ADR-0030, keyed by recipient), and a non-recipient row has no consumer. B buys a round-trip with no disclosure to rule on; C spends code on rows nobody can read. Long-term soundness: A fixes the producer so the invalid row is never written (contract-first, no consumer-side tolerance); C is a one-off migration for self-expiring data. Guarding against AI authoring errors: A makes the write path refuse to produce the row at all, the structural form; B and C add nothing there. Startup focus: A is the smallest change; C widens scope; B adds no scope but costs a dispatch."
}
],
"out_of_scope_findings": [
"carrier: none (承接者:无) · noted, not filed — plugin-security default-permission-sets.ts, the _self comment above sys_inbox_message_self says neither inbox object declares organization_id so Layer 0 is inert on them; measured on main b88c356, the registry injects organization_id into sys_notification_receipt (engine-owned, not better-auth), and the tenant wall plus the driver's native scope do act on it (narrowing only). Comment drift, no behaviour defect.",
"For the build, read on main b88c356 (not a finding): markAllRead needs no change, because unreadNotificationIds derives ids from the user's own inbox rows that carry a notification_id, minus read-class receipts, so every id it passes has an inbox message for that user. The inbox channel's delivered receipt is keyed (notification_id, user_id, channel inbox) with state delivered and is best-effort (skipped when the event id is absent, and the inbox row stands when it fails), so the delivered check must accept an inbox message on its own. An inbox row with no notification_id (#6448 remains open) has no event id to name; a mark-read naming such a row's own id would find neither half and write nothing, the same unread outcome markAllRead already gives those rows."
]
}