Resolves #16054.

The actual defect was ours, and it shipped

ai/deploy/docker-compose.yml pinned NEO_MAILBOX_DEFAULT_REPLY_POLICY=blocked, overriding the library leaf default of open. Every deployment that followed our own guide inherited it. Members of a single organisation's private deployment could not message each other at all — each pair needed an explicit CAN_REPLY_TO grant first. On a 15-member team that is 210 directed grants, and 28 more per hire, to obtain the thing the product is for.

Install the mail system, then send postal letters asking for permission to send mail.

The value found on a live deployment came from this file, rendered into their compose. An earlier revision of this PR recommended that the tenant set an env var to undo it — that was asking a customer to pay for our default, and it is withdrawn.

It was also incoherent with its neighbour. memorySharing.defaultPolicy defaults to team, so the same template let every member read every other member's memories while forbidding them a message: the more sensitive permission granted alongside the less sensitive one refused. Both leaves answer ONE question — is this deployment a single trust boundary or several — and the template answered it two ways.

Removed rather than restated as =open: pinning the library default in a second place duplicates it and silently freezes today's value if the leaf changes. The leaf owns it. blocked stays correct for a genuine multi-tenant install, which sets it explicitly together with NEO_MEMORY_SHARING_DEFAULT_POLICY=private.

The rest of this PR is the message half, below.

The message half: naming the posture

One refusal message, and it matters more than its size.

Before: Unauthorized: Cannot send to @x. Requires CAN_REPLY_TO permission or prior message history.

True, and it sends the reader to the wrong remedy. It reads as a per-pair problem, so an operator acts per pair — on a 15-member single-org deployment that is 210 directed grants, and 28 more per hire. The actual cause is a deployment-level selector resolving to strict isolation, where one policy change replaces all of them.

Evidence: found live on a private single-org deployment, and the shape is why this is a defect rather than a documentation gap:

Every member could read every other member's stored reasoning while none could send another a message. Reading memories is strictly more sensitive than pinging someone, so that pairing is almost certainly unintended — and the refusal gave no hint that a policy decided it, so the only visible lever was the grant.

The message now names the resolved policy, says what that posture is for, and points at changing it rather than granting each pair.

Three deliberate boundaries

• Names the config path, not the env var. The env binding is discoverable from the leaf; hard-coding NEO_MAILBOX_DEFAULT_REPLY_POLICY into a runtime string would rot the moment the binding is renamed.
• CAN_REPLY_TO stays named. A genuinely cross-boundary send still wants the per-pair grant, and naming the posture must not hide the legitimate remedy. Asserted.
• The sibling BLOCKED_BY refusal is untouched. An explicit block is a per-pair decision; steering that reader toward a deployment-wide policy change would advise overriding someone's stated intent.

Test Evidence

• 143 passed — ai/deploy/ (incl. the new trust-defaults guard) + MailboxService.spec.mjs.
• The trust-defaults guard binds the PAIR rather than banning a value, because banning blocked would break the multi-tenant template that legitimately wants it. Its first assertion is a positive control that the parser sees the environment blocks at all — the other two are absence checks, which pass over an empty map. Certified by mutation: re-pinning the line fails both invariants while the control stays green.
• 1524 passed — derived suite: services/memory-core + memory-core Server + kb-alerting + scripts/lifecycle.

The fixture asserts all three properties: the policy is named, the per-pair remedy is discouraged, and the grant path stays discoverable. It cannot pass against the old message, which contained neither of the first two strings — so it is non-vacuous by construction rather than by label.

One honest note. An earlier run of that suite showed a single failure in SessionService.ResumeValidation.spec.mjs:314, and a clean-dev control of the identical batch passed — which looked like attribution to this change. It did not reproduce: the same batch then passed twice with this change present, plus two further passes of the containing directory. A one-run A/B cannot attribute an intermittent failure, which is what I did initially. That spec's neighbours assert lease expiry against wall-clock time, so a clock-boundary flake is the likely class. Recorded rather than claimed resolved, and not attributed to this diff.

Follow-up, not a gap in this PR

#16054's stated problem — members of a private deployment cannot message each other without pairwise grants — is fixed here: the template no longer imposes it, so the library's peer-trust default governs. What remains is a hardening, not an unmet AC of this ticket: the posture-derived default, deriving mailbox.defaultReplyPolicy from memorySharing.defaultPolicy ('team' ⇒ 'open', 'private' ⇒ 'blocked') so the incoherent pairing above becomes unrepresentable rather than merely discouraged. That needs no new axis — memorySharing.defaultPolicy's own documentation already draws the tenancy line ("Multi-tenant SaaS deployments … MUST override to private").

It wants its own ticket because it is a cross-leaf derived default that must still let an explicit env override win. leaf(default, env, type) cannot reference another leaf at declaration time, so it is either a formula honouring an explicit override or a two-leaf shape with the derivation at the use site — ADR-0019 primitive-adjacent, and §6 requires citing Provider.mjs / createHierarchicalDataProxy.mjs / ConfigProvider.mjs before changing the primitive. That is a shape decision, not an implementation detail.

Deltas

• ai/services/memory-core/MailboxService.mjs — the strict-mode refusal names the posture; the BLOCKED_BY refusal untouched.
• test/playwright/unit/ai/services/memory-core/MailboxService.spec.mjs — one fixture, three assertions.

Post-Merge Validation

• Takes effect immediately for any deployment resolving 'blocked'; no migration, no config change required.
• The affected deployment's one-line unblock is independent of this PR and available now: set the mailbox reply policy to open. This PR ensures the next operator to hit the refusal is told that, instead of discovering it after 210 grants.

Authored by Vega (@neo-opus-vega). Session c038696f-94a6-4788-82bf-747c5672908c.