MessagingService.listInbox has the same free-userId shape markRead just lost — any in-process plugin can read any user's inbox

[os-sam]

Measured while implementing the authenticated-caller scoping for the inbox write door (#10753 / PR #11450). Filing rather than folding in: the ruling on #10753 names markRead and recall, so the read side is outside that card's scope.

The shape

MessagingService.listInbox(userId, opts) (packages/services/service-messaging/src/messaging-service.ts:372) keys its whole read on the caller-supplied userId:

• where = { user_id: userId } against sys_inbox_message (:378)
• readReceiptStates(data, userId) → where: { user_id: userId, channel: 'inbox' }

On the REST path that parameter is trustworthy — packages/runtime/src/domains/notifications.ts:175 binds it to context.executionContext.userId and answers 401 when there is none. But the service is also registered as a kernel service (ctx.registerService('messaging', service), messaging-service-plugin.ts:162), and the kernel hands every plugin one shared PluginContext (packages/core/src/kernel.ts:65,:91) whose getService carries no caller identity.

So for an in-process caller userId is a free string, and the read lands context-lessly on sys_inbox_message / sys_notification_receipt — the latter managedBy: 'engine-owned' with apiMethods: ['get','list'] (ADR-0103) — so no engine permission check sees it either.

⇒ Any plugin can read any user's inbox titles, bodies and read-state. This is the exact shape PR #11450 removed from the write side, on the read side, and it is arguably the more sensitive half: inbox bodies carry rendered business content.

Why it was not fixed in PR #11450

That PR's ruling (comment 5386675655) covers the write verbs only. Widening it to the read side without a ruling would be scope creep on a card whose whole point was that public-surface widening is the maintainer's call.

Suggested shape (not a decision)

The same one PR #11450 landed: a plugin-facing listInboxAsCaller(caller: ExecutionContext, opts) that derives the recipient from caller.userId and refuses with InboxCallerError (401 UNAUTHENTICATED) otherwise, reusing resolveInboxRecipient from packages/services/service-messaging/src/inbox-caller.ts. listInbox(userId, opts) stays as the published INotificationService contract the REST door needs.

Note the same honest caveat that PR applies to itself: this is a discipline boundary, not a security boundary — an in-process plugin already holds the data engine.

Links

• Chain parent: Console 顶栏铃铛未读角标在审批处理完成后不更新 #10753
• Landed write-side counterpart: feat(messaging): scope the plugin-facing inbox writes to the authenticated caller #11450

[claude]

Triage (daily round, session session_01Kktexqp6uVuFMztvvTMf3V, 2026-08-24): lands in service-messaging read door → domain:services + security + pm:queue, Bug. Restores the same authenticated-caller invariant PR #11450 established on the write side; the #10753 ruling fenced that card to markRead/recall, so this is the read-side sibling, dispatchable on the established pattern. Serial note: same file as PR #11450 — verify it is merged before dispatch or serialize behind it.

---

Generated by Claude Code

[os-sam]

Claimed by the domain:services execution seat — PM session session_01APWX2AwT3a4xDcjPCe8bk4, branch claude/issue-11452-listinbox-as-caller. Now pm:dispatched.

Serial precondition from triage is satisfied: PR #11450 (the write-side counterpart, card #10753) is merged, so packages/services/service-messaging/src/inbox-caller.ts and resolveInboxRecipient exist on main and the dev branches from a tree that already contains them. No serialization needed.

Dispatch fences carried to the dev:

• ⛔ No packages/spec/** edits. listInbox(userId, opts) stays exactly as the published INotificationService contract — the REST door at packages/runtime/src/domains/notifications.ts:175 depends on it. If closing the read side turns out to require a spec edit, stop and report so the contract half can be split to the spec seat (the Should a definition-level input-schema refusal be non-retryable? #9889's parity floor makes a flow burn its whole retry budget on a verdict that cannot change #10025 → spec: widen AutomationResult.code + register a never-dispatched ADR-0112 code for the definition-level input-schema refusal — the contract half of #10025's ruled Option B #11504 and /api/v1/analytics/query still drops per-measure and dataset-level filter on the ObjectQL path — engine.aggregate receives no filter at all #10413 → engine.aggregate: add per-aggregation filter to the contract — ruled half of #10413 (measure-level filters on the ObjectQL analytics path) #10576 precedent).
• The new door is additive: a plugin-facing listInboxAsCaller alongside, never a signature change to the existing method.
• This is a tightening, so it is inside seat discretion — but it must reuse PR feat(messaging): scope the plugin-facing inbox writes to the authenticated caller #11450's shape rather than invent a second refusal vocabulary.
• Carry PR feat(messaging): scope the plugin-facing inbox writes to the authenticated caller #11450's own honest caveat forward verbatim in the PR body: this is a discipline boundary, not a security boundary — an in-process plugin already holds the data engine. Do not let the PR read as a stronger claim than the change supports.
• Disclosure discipline: the card is already public and states the shape, so the PR may reference it — but add no new reproduction detail beyond what MessagingService.listInbox has the same free-userId shape markRead just lost — any in-process plugin can read any user's inbox #11452 already says.

---

Generated by Claude Code

[os-sam]

os-dev-report

{
 "issue": 11452,
 "status": "done",
 "branch": "claude/issue-11452-listinbox-as-caller",
 "pr": "https://github.com/objectstack-ai/objectstack/pull/11536",
 "premise_still_valid": true,
 "summary": "Added the plugin-facing inbox read door listInboxAsCaller(caller, opts) to MessagingService, mirroring PR #11450 exactly: recipient derived from caller.userId via the shared resolveInboxRecipient, InboxCallerError (401 UNAUTHENTICATED) otherwise, refusal evaluated before listInbox's empty-envelope short-circuit. listInbox stays byte-for-byte; no spec edits were needed (the new method lives on the service class, like the write door). resolveInboxRecipient gained an optional third parameter naming the target-user door its refusal prescribes — defaulting to the write door's existing text so #10753 refusal bytes are unchanged. Premise re-measured on main at c2dd951474: listInbox still keyed on the free userId, no listInboxAsCaller anywhere, no PR referencing 11452 in title or body.",
 "tests": "All at PR head 90b3528079, exits captured before any pipe. Package suite + typecheck: 'Test Files 26 passed (26) / Tests 274 passed (274)', tsc clean. Ablation (naive caller?.userId ?? '' delegation): mutation confirmed on disk (injected-count=1, removed-anchor-count=0), exactly the 5 refusal tests red with the predicted 'expected InboxCallerError, but the call resolved', restore byte-identical (git hash-object ace6fc2b… both sides); suite resolves subject via relative src imports so no rebuild leg applies. Derived gate union (dispatch-gates.mjs, derivation stamped at 90b3528079): 17 path/kind-matched gates all exit 0; check:type-check-debt 're-measured 32 ledger entries, none above its recorded number' after full closure build; check:i18n 'all bundles in sync'; check:nul-bytes OK; targeted eslint on the 3 touched TS files exit 0.",
 "not_measured": "Repo-wide eslint sweep (CI-owned; targeted run on touched files only — narrowing declared), full cross-package consumer test sweep beyond the derived union, and remote CI at the time of this report (report delivered at draft-PR time per standing rule; CI in_progress).",
 "fences": "No spec edits needed or made; no releases/ edits; listInbox untouched; single refusal vocabulary reused. Closest approach: the shared resolveInboxRecipient's refusal text hard-coded the write door as its prescription — resolved additively (optional param, write-door default) rather than a second vocabulary or a byte change to #10753 refusals.",
 "escalate": "Nothing blocking. Note for scheduling: verify-lock contention cost ~25 min of queue time this round (two exit-99 timeouts and one 10-min-cap kill of a full-closure build at 66/68 tasks; warm-cache retry then finished in 18s) — consistent with the #11363 tracking.",
 "open_questions": [],
 "out_of_scope_findings": []
}

---

Generated by Claude Code

---

Generated by Claude Code