Claustrum enrollment polls a superseded request forever, from every process, with no log

[iceteaSA]

v1.23.0's consumer-enrollment ceremony polls an expired request indefinitely, from every OpenCode process on the host, and survives restarts. Nothing is logged on our side, so the vault operator found it before we did.

Observed on a host running handle/manifest custody (claustrum.mode: "claustrum", no primaryAccount). Nobody ran setup or asked to enroll.

What happened

time (UTC)	event
09-22 19:40:47	first boot on v1.23.0 creates opencode-enrollment-state.json (phase: pending, no requestId)
09-22 19:40 → 09-23 06:42	every process retries the propose against a Claustrum build that does not serve auth.enroll_propose
09-23 06:42:06	new Claustrum build accepts it; requestId written (vault: auth.enroll_propose seq 336)
06:42 → 06:57	~2.2 polls/s, all pending (~2,000 polls)
06:57:06	request expires on schedule (auth.enroll_expire)
06:57 → now	every poll answers superseded; polling continues at ~22/min

Only one propose was ever sent. The polling is the problem.

Causes, from source

1. Trigger is config state at plugin init, not an explicit action. packages/opencode/src/index.ts:1283-1287:

if (isScopedCustodyActive(initialStorage)) {
  getOpenCodeScopedRuntime(accountStoragePath, ctx.directory).start()
} else if (getClaustrumMode(initialStorage) === 'claustrum') {
  ensureClaustrumEnrollmentAdoption()
}

Any handle-custody install that hasn't finished the zero-bind upgrade takes the second arm on every boot. The status projection at :5613 re-arms it too. I understand this is how setup upgrades an install, but it fires whether or not the operator has started that upgrade.

2. superseded never becomes terminal. The manager has two terminal outcomes: denied, and blocked for non-retry error classes. A superseded reply comes back with a retryable class, so reconcile returns pending with a retryCode, and the registry reschedules at RETRY_POLL_MS (60 s). The on-disk state stays pending.

3. Restarting doesn't stop it. The requestId is persisted. A fresh process reads phase: pending plus the requestId, skips propose, and polls the dead id again. Every future process inherits the loop.

4. Cadence scales with process count. PENDING_POLL_MS = 5_000, one registry per process, no attempt cap. With 11 OpenCode processes that is 11 × 0.2/s = 2.2/s against one pending request. A developer with many sessions open multiplies the load on the vault's single writer.

5. The ceremony is silent. onStatus logs only transitions into unavailable or approved. A pending with a retryCode covers the whole failure: 11 h of rejected proposes, ~2,000 pending polls, and the superseded loop. It produced zero lines in /tmp/opencode-anthropic-auth.log across four rotated generations. The vault found this from its own audit rows.

Suggested fix

• Treat superseded and expired as terminal for that request id. Either re-propose once with a fresh secret or persist a terminal phase that /claude-account enrollment-reset can clear. Never retry a dead id.
• Don't start the ceremony on boot for a handle-custody install. Tie it to setup or an explicit command, or at least to an opt-in config flag.
• Make the poll cadence independent of process count. One poller per host (the ceremony lock already exists), or back off exponentially with a cap.
• Log every ceremony state transition, including pending → pending when the retryCode changes.

Cost today is bounded: each poll writes one row into a 64-row ring for the poll key, and no credential ring is touched. But the loop never ends on its own, and it grows with every process a user opens.

Local state

~/.local/state/cortexkit/anthropic-auth/opencode-enrollment-state.json (0600): phase: pending, requestId set. Deleting it would mint a new secret and re-propose, which starts a fresh 5 s × N-process storm and then the same superseded loop 15 minutes later. enrollment-reset refuses because the phase is pending. There is no supported way to stop the loop short of editing the state file by hand.

[iceteaSA]

Correction to cause 2, and a new doubling

The Claustrum maintainer read the vault source, and I checked their account against the installed @cortexkit/claustrum-client@0.3.0. Two of my claims above were wrong.

Cause 2 as I wrote it was wrong. I inferred that superseded arrives with a valid but transient class, because the client's unknown-class logger never fired. That is backwards. The vault sends superseded as permanent (credentials-core enrollment.rs:57-66; the only transient refusal is pending_queue_full). But enrollment refusals don't use the read-surface envelope. They go out as a subc Error frame with body {"code":"superseded","disposition":"permanent"}. There is no class field at all. Two layers then lose the permanence:

• @cortexkit/subc-client@0.8.1 errorFromFrame keeps only {message, code}, so disposition is dropped. It surfaces as a SubcCallError of kind terminal with code superseded.
• claustrum-client wire.js:278-283 #asTransportError then hard-codes the class:

  const code = error instanceof SubcCallError && error.code ? error.code : 'transport_error';
  return new ClaustrumCredentialError(code, 'transient', 'retry');

  asCredentialError, the only path that calls the unknown-class logger, is never reached for an Error frame. That's why nothing was logged, not the reason I gave.

Every poll after expiry is sent twice. wire.js:258-273 #call treats any terminal SubcCallError as a lost connection. It reconnects and re-sends the same call before converting the error. The vault's poll ring shows it: 30 of 32 pairable rows sit 1–18 ms apart. The rate confirms it. Before expiry, pending is a successful response and polls ran at 11 processes × 0.2/s = 2.2/s. After expiry, every reply is an Error frame and polls run at 22/min = 11 × 1/min × 2. The doubling starts exactly when the reply becomes an error. Each of those resends also pays a fully re-authenticated daemon reconnect. I had attributed the pairs to two processes; that was wrong.

The design already calls this terminal

packages/core/src/claustrum-enrollment-registry.ts:144-146:

only the manager persists protocol-terminal outcomes such as denied, superseded, or already_consumed.

The manager decides terminality by error.action !== 'retry'. The transport forces action = 'retry' for every Error frame, so superseded can never reach the terminal branch the comment describes.

Split of the fix

• This repo, now: code does survive both layers (ClaustrumCredentialError.code === 'superseded'). So the manager can decide terminality by code: superseded, not_found, already_consumed, and expired if the vault sends it. Check these in both the propose and poll catch blocks, before the action === 'retry' test. That ends the loop without waiting on the client. I'll open a PR.
• Claustrum side (being filed on cortexkit/claustrum): the client must not reconnect on a module-originated Error frame, and must carry disposition through instead of substituting transient. The underlying cause is the split wire format — enrollment sends {code, disposition}, reads send {class, code}.

The other causes stand as written: the ceremony starts at init for handle-custody installs (1), the persisted requestId survives restarts (3), cadence scales with process count (4), and there is no logging (5).

[iceteaSA]

The transport half is tracked in cortexkit/claustrum#69: the enrollment wire split, subc-client dropping disposition, and claustrum-client reconnecting on a module refusal and relabelling it transient. It's confirmed still present on claustrum master 4be8402, and it carries the pair measurements. Treat that part of my comment above as context; #69 owns it.

This issue is the consumer side only: the manager should treat superseded, not_found and already_consumed as terminal by error.code (the code survives today's client), start-on-init for handle-custody installs, cadence that scales with process count, and no logging.

[iceteaSA]

@ualtinok, one list of everything I have open. I re-checked each against current main (4a01612) tonight. None has been fixed elsewhere or superseded by v1.23.0, so I've closed nothing. Each open thread has had its own follow-up with current main line numbers.

Claustrum enrollment (newest, currently live in production)

• Claustrum enrollment polls a superseded request forever, from every process, with no log #255 (this issue): the enrollment ceremony polls a superseded request forever, from every process, and restarts don't stop it. fix(claustrum): stop polling an enrollment request the vault has refused permanently #256 is the consumer-side fix: it treats superseded, not_found and already_consumed as final by error code. It stops the loop fleet-wide from the first process that starts on it. The client half is in claustrum-client turns every enrollment refusal into a transient error and re-sends the call claustrum#69.

Custody

• fix(custody): credential-presence gates and reported-failed version refusal #232: credential-presence checks, a stale vault account admitted during a refresh error, the vault TTL moved into a shared helper, and the golden fixture checker's source repo. 177 production lines main lacks. Green.
• fix(claustrum): retry rotated vault credentials before reporting a 401 #233, stacked on fix(custody): credential-presence gates and reported-failed version refusal #232: retries a vault 401 once with a fresh credential and reports the version that was actually sent. Now also passes the scoped attempt through, so v1.23.0's zero-bind 401s actually get reported (they were being dropped). Green.
• fix(core): reject empty segments in custody credential IDs #236: rejects empty segments in custody credential IDs, to match Claustrum's tightened parser. Green.
• Custody boot gate withholds fallback background refresh silently — no log, no sidebar signal #239 → fix(custody): make the withheld fallback refresh observable #240: the custody gate that holds back fallback background refresh now says so, in the log and the sidebar. Green.
• test(custody): pin cross-tenant manifest isolation #243: a test pinning that foreign blocks in the shared handle manifest are left alone. Green.
• fix(custody): treat an undefined watch filename as a directory-level change #246: fixes the fs.watch crash on an undefined filename in the manifest watcher. This is the "1 error" red CI other PRs have been hitting. Green.

Fable 5.1 effort markers: #237

• fix(opencode): accept effort-marked Fable 5.1 tool continuations #238: tool-continuation anchor. Red only because of the fix(custody): treat an undefined watch filename as a directory-level change #246 crash.
• fix(fable): accept effort markers on a merged user boundary #241: multiple markers on one merged boundary. Green, and live since 09-19.
• fix(fable): make the effort-marker trim tolerance reachable #242: correlation tolerance for a full trim, plus a plan history. Green. It conflicts with fix(opencode): accept effort-marked Fable 5.1 tool continuations #238 in one test; I'll resolve that after whichever merges first.

CI

• ci: record test-count floors (data only, no gate) #234 / ci: add test-count floor gate with merge-target ratchet #235: test-count floors and the ratchet gate. The floors predate v1.23.0 and need refreshing from a green CI run if you want the gate.
• Two async-timing tests are flaky on CI: identical trees give different failures #220: intermittent tests. One correction to what I said earlier: starts a durable enrollment ceremony fails even in isolation on an unloaded machine, 2 of 4 runs on clean main. It isn't only load-sensitive.

Suggested order if useful: #246 first (unblocks other PRs' CI), then #256 (live loop), then #232 → #233.

[iceteaSA]

Fixed by 61a3e35 (enrollment now happens only through explicit offline setup, never on plugin boot), with 2e18b43 and bec7b09 classifying producer-permanent refusals. The live check against #256 on 2026-09-23 showed a written blocked state stopping all 11 older processes within one poll tick, with no restart. The transport half is tracked in cortexkit/claustrum#69.

[ualtinok]

Reopening until the fix reaches users. main@6ddfdb13 removes enrollment proposals/polls from OpenCode boot and account status; explicit offline setup resumes and, for a daemon-proven dead request, renews once under lock. Core also treats Claustrum’s permanent refusal codes as terminal even when the older client labels them retryable. The clean CI run passed, but npm 1.23.0 and already-running processes still have the old polling behavior. Those processes must stop or restart to adopt the new code; this new build does not automatically poll a pending request to heal older processes.