test(custody): pin cross-tenant manifest isolation

[iceteaSA]

Tests only. No production change — this pins behaviour that is already correct but currently unasserted.

Why

opencode-handles.json is a shared, co-tenant manifest. Blocks are keyed by provider + serve; ours is anthropic / anthropic-auth. Sibling plugins own their own blocks and evolve them independently.

A sibling tenant is adding an optional minTtlMs key to the account objects in their block and asked us to confirm we tolerate it. We do — structurally:

• Reader — readCustodyHandles (packages/core/src/claustrum.ts:482) filters json.providers to entry.provider === provider at :501-506 before any account parsing, then selects on entry.serve === serve at :508. Foreign blocks never reach the account loop.
• Writer — writeCustodyHandleManifestEntryLocked :1424 passes foreign blocks through by identity (providers.map((p, i) => i === blockIndex ? {…} : p)), never re-serialising them from a parsed model.

Neither property was pinned by a test. Both are consequences of current statement order and object-spread choices. A refactor that validated accounts before filtering by provider, or rebuilt the providers array instead of mapping it, would silently make a foreign tenant's block reachable — or drop it — and nobody would find out until a live shared manifest took someone dark.

The tests

• reads our accounts while ignoring a foreign block with unknown account keys — a foreign block carrying minTtlMs beside ours; our read returns our accounts with corruptLabels empty.
• reads our accounts while ignoring hostile foreign provider entries — foreign accounts that is not an array, plus null, 42, and a {provider}-only object as siblings in providers[]; our read still succeeds.
• preserves a foreign block unknown key byte-identically when writing our account — writes a new account into our block and asserts the foreign block is serialise-identical afterwards.

Verification

Both mutations break the isolation, not the tests:

mutation	result
remove the provider and serve filters so the account loop sees a foreign block	reads our accounts while ignoring a foreign block with unknown account keys — Expected -7 / Received +1
writer serialises only our own block, dropping foreign ones	preserves a foreign block unknown key byte-identically when writing our account — Expected -6 / Received +6

My first attempt at the reader mutation was too weak and passed. Removing only the provider filter leaves the serve selector at :508, which still lands on our block — a no-op for this fixture. That was my mutation being wrong, not the test being vacuous; removing both filters reddens it. Worth stating because a mutation that fails to redden looks identical to a test that does not work, and the difference is which one you fix.

The write-status assertion in the third test is deliberately first, before any preservation assertion. writeCustodyHandleManifestEntry returns {status:'refused', reason} rather than throwing, so a round-trip test that skips that check reads the untouched original file and reports preservation that never happened. That is exactly how my initial hand-probe of this produced a false positive.

Gates: core 199/0 · opencode 1897/0 (1894 + 3) · typecheck clean.

Known limit, stated rather than implied

Our preservation is by construction, not by assertion — there is no post-mutate check that foreign blocks are unchanged. The sibling tenant's writer asserts it inside their locked write, so their regressions fail at the writer; ours would fail only at test time, once these tests exist. Converging on a writer-level assertion is the better end state; this PR closes the gap that is cheap to close now.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

---

Summary by cubic

Adds regression tests pinning cross-tenant isolation in the shared opencode-handles.json. No production change — these assertions guard a refactor from silently letting a foreign tenant's block reach our validator or get dropped on write.

Tests

• Reader ignores a foreign block carrying an unknown minTtlMs account key and returns only our accounts with no corruption.
• Reader also ignores hostile foreign entries: non-array accounts, null, a number, and a provider-only object.
• Writer preserves a foreign block byte-identically when writing our account; the write-status check runs first so the round-trip assertion can't pass on an untouched file.

Foreign-block preservation is by construction rather than asserted post-write, so a writer regression would surface only at test time.

^{Written for commit 8c28000. Summary will update on new commits.}

Confidence Score: 5/5

The PR appears safe to merge; no new correctness or security issues were introduced.

Findings

1.  Provider filter remains unpinned ▶
2.  Byte identity is overstated ▶

Summary

This PR adds regression coverage for cross-tenant isolation in the shared custody-handle manifest.

• Verifies reader logic ignores unknown and malformed foreign-provider entries.
• Verifies writing an Anthropic account retains a foreign provider block and its unknown account fields.
• No production behavior is changed by the PR.

_{Reviews (2) · Last reviewed commit: "test(custody): pin cross-tenant manifest..."}

[iceteaSA]

Rebased onto main at v1.23.0, no conflicts.

This is the PR v1.23.0 could have invalidated, so I checked it hardest. The release adds zero-bind scoped Claustrum custody, which discovers vaulted accounts "without manual capability handle minting, manifest files, or process restarts". If the manifest path were now dead code, pinning its cross-tenant behaviour would be pinning a corpse.

It is not dead. Non-test references on main:

readCustodyHandles                 4
writeCustodyHandleManifestEntry    7
removeCustodyHandleManifestEntry   5
resolveCustodyHandle              15

Zero-bind is an additional discovery path, not a replacement — v1.23.0 still ships startup legacy-handle migration and bound-account resolution through the manifest. packages/core/src/claustrum.ts and custody-handle-manifest.test.ts are both byte-identical to this PR's base.

The cross-tenant contract is also live independently of our own custody mode: a sibling tenant is writing a new optional account key into its own block in the shared opencode-handles.json now. Our reader must keep ignoring their block and our writer must keep round-tripping it whichever path our accounts resolve through.

Pre-existing failures are upstream's

Two failures on the full opencode suite, both reproducing on clean upstream/main with none of this PR's changes: vault reauth leaves the account absent and projects the reauth state (passes alone, fails in-suite) and starts a durable enrollment ceremony in Claustrum mode without enabling scoped serving (load-sensitive). Identical set with and without this branch. Matches #220.

Typecheck passes; core 295/0.

[greptile-apps]

Provider filter remains unpinned

Both new reader fixtures give the foreign block a different serve value as well as a different provider. The existing serve selector would therefore still exclude these blocks if provider filtering were accidentally removed, so the tests would not catch that regression. Using a foreign provider with serve: 'anthropic-auth' would independently exercise the provider boundary.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

Byte identity is overstated

The test parses the file and serializes both objects with the same formatter before comparing them. This checks structure and key order, but cannot detect changes to the foreign block's original whitespace or formatting; the writer also reformats the complete document. Rename the test to describe structural or key-order preservation rather than a byte-level guarantee.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!