fix(custody): carry the vault credential id in manifest bindings

[iceteaSA]

Found by attempting the custody flip on a live deployment. The preflight refused, correctly, and the refusal was unfixable from config — the main account's vault credential id cannot be expressed in the handle manifest at all.

The blocker

The manifest binds an account label to a Claustrum credential id. The parser derived the expected id from the label (oauth:anthropic:<label>) and rejected any entry that disagreed. Main's credential lives on the unlabelled provider-default lane, oauth:anthropic, so both encodings refuse:

credential_id	outcome
oauth:anthropic (the real one)	corrupt-binding at parse
oauth:anthropic:main (the derived one)	credential_identity_mismatch at runtime — the vault returns the real id

Verified against the parser before writing anything, and again after the fix:

corrupt: []
  main     -> {"status":"resolved","credentialId":"oauth:anthropic"}
  work-alt -> {"status":"resolved","credentialId":"oauth:anthropic:work-alt"}

Not specific to main. antigravity:google is unlabelled the same way; anything whose id does not happen to match its label hits this.

Why carry the id rather than special-case main

A derived identifier encodes a convention as a constraint. Conventions change; parser constraints do not.

The parse-time equality check compared the manifest against itself — two fields the same writer wrote in the same breath. It can catch corruption, not a wrong id. The check that means something is the runtime fence in custody-mode.ts:

credential.credentialId !== binding.credentialId -> refuse

That one has vault ground truth on one side. It is unchanged here. Dropping the derivation loses no failure path: a typo'd id gets not_found from the vault (uniform mask, fails closed), a mismatched id gets the fence.

Special-casing main would leave the derivation in place and add an exception to it — working today, broken again at the next unlabelled credential.

Changes

• readCustodyHandles carries credential_id verbatim; all other validation (handle shape, label validity, superseded parsing, corrupt-label path) is untouched.
• resolveCustodyHandle matches on label and returns the entry's own id.
• Duplicate-label guard, new. The label is now the sole lookup key, so two entries sharing one had to stop silently resolving to whichever came first — every entry with a duplicated label goes to corruptLabels. This replaces what the derivation was incidentally doing.
• Preflight freshness gate. It passed refresh_floor + 30min (~4.5h) to cache.get. In Claustrum that value is a staleness floor — a get below it forces an upstream refresh, so a readiness check silently rotated the credential it was about to use. Because the vault refreshes on a cadence close to the token lifetime, a credential sits below a 4.5h floor for most of its cycle: main is below it for ~4.5h of every ~8h. Replaced with a 5-minute serving margin (CUSTODY_PREFLIGHT_MIN_TTL_MS). The vault owns rotation; the preflight only needs the credential to serve the takeover.
• Refusal text for TAKEOVER_INCOMPLETE_MAIN_REAL pointed at ck auth migrate-plugin, which exists on no deployed Claustrum binary — it is parked on an unmerged branch. Reworded to the supported path (ck auth mint-handle; this plugin writes the manifest entry).

Verification

Each behaviour is pinned by a mutation of implemented logic, not a missing symbol.

• Restoring the derivation reddens both new manifest tests: returns the entry's own credential id verbatim (Expected "resolved", received "unresolved") and the duplicate-label test (Set {} vs Set { "alice" }).
• Restoring the 4.5h floor reddens preflight hands a small serving margin to cache.get even when expiry is far below the refresh floor — the credential expires in 1h, comfortably above the 5-minute margin and far below the old floor. The test asserts the argument handed to cache.get, not just the outcome, so it cannot pass for the wrong reason.
• Restoring the old guidance reddens the ck auth mint-handle assertion.
• core 188/188 · opencode 1872/1872 · pi 114/114 · typecheck, format, biome clean.

Not included

Whether main should eventually be re-homed onto a 3-segment id in the vault. That is a real option with a migration — Insula's handle binding, the sealer, both recorders, the latch-watch and the rotation probe all key on the literal oauth:anthropic — and it should not happen as a side effect of unblocking a flip.

---

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

---

Summary by cubic

Fixes custody takeover preflight being blocked for credentials whose vault id doesn't match their label, like the main account's oauth:anthropic. The manifest previously derived the expected credential id from the label and rejected real ids at parse time; it now carries credential_id verbatim, and the runtime fence in custody-mode.ts remains the authority.

Bug Fixes

• Duplicate labels now mark every sharing entry as corrupt instead of silently resolving to the first one.
• Preflight passed refresh_floor + 30min as min_ttl_ms to cache.get, which treats it as a staleness floor and forced an upstream refresh during a readiness check; it now uses a 5-minute serving margin (CUSTODY_PREFLIGHT_MIN_TTL_MS).
• TAKEOVER_INCOMPLETE_MAIN_REAL guidance pointed at the nonexistent ck auth migrate-plugin; it now suggests ck auth mint-handle.

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

[cubic-dev-ai]

1 issue found across 8 files

Confidence score: 3/5

• In packages/core/src/claustrum.ts, local login can resolve a valid vault credential under a non-derived ID but fail to remove that manifest binding because cleanup still enforces oauth:anthropic:${label}; this can leave stale custody state behind. Update cleanup to use the resolved credential ID and add coverage for mismatched IDs.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="packages/core/src/claustrum.ts">

<violation number="1" location="packages/core/src/claustrum.ts:412">
P1: When a valid vault credential ID differs from `oauth:anthropic:${label}`, local login resolves the new manifest binding but cannot clear it because `removeCustodyHandleManifestEntry` still enforces the derived ID. Accept any validated non-empty credential ID in the removal validation.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: When a valid vault credential ID differs from oauth:anthropic:${label}, local login resolves the new manifest binding but cannot clear it because removeCustodyHandleManifestEntry still enforces the derived ID. Accept any validated non-empty credential ID in the removal validation.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At packages/core/src/claustrum.ts, line 412:

<comment>When a valid vault credential ID differs from `oauth:anthropic:${label}`, local login resolves the new manifest binding but cannot clear it because `removeCustodyHandleManifestEntry` still enforces the derived ID. Accept any validated non-empty credential ID in the removal validation.</comment>

<file context>
@@ -388,13 +409,15 @@ export function readCustodyHandles(
-      !isValidCustodyCredentialId(entry.credential_id) ||
-      (provider === 'anthropic' &&
-        entry.credential_id !== custodyCredentialId(entry.label))
+      !isValidCustodyCredentialId(entry.credential_id)
     ) {
       corruptLabels.add(entry.label)
</file context>