fix(secrets): the Claude coding-plan token had no slot to arrive through

[POWERFULMOVES]

The bug

archon boots healthy, passes its health check, and dies on the first workflow:

errorCode: "billing_error"  apiErrorStatus: 400
"Credit balance is too low"

The cause is not a missing value. It is a missing slot.

Layer	State on main
env.tier-agent.example:79-83	declares CLAUDE_CODE_OAUTH_TOKEN (since #2359)
docker-compose.yml / .agents.yml	wire ${CLAUDE_CODE_OAUTH_TOKEN:-} into archon
CHIT registry	no entry — the funnel has no route for it
live env.tier-agent	carries none of the five Claude auth vars the example promises

Meanwhile ANTHROPIC_API_KEY is a registered slot, is set fleet-wide from env.shared, and the Claude CLI prefers it over the OAuth token. Archon says so in its own source (packages/providers/src/claude/provider.ts:144):

// the CLI prefers ANTHROPIC_API_KEY over the OAuth token, so injecting the install key alongside it would silently rebill the run

So the metered key wins and the coding plan never gets a chance. MODEL_FABRIC_CONTRACT.md:44 already lists Claude Code Max in the approved coding-plan inventory — this is a missing slot, not a new policy decision.

The change

Registered via the sanctioned path only: registry entry, then chit-manifest-register, then chit-manifest-sync. No manifest was hand-edited.

- id: claude_code_oauth_token
  source: {type: cgp, label: CLAUDE_CODE_OAUTH_TOKEN}
  targets:
    - {file: .env.generated,  key: CLAUDE_CODE_OAUTH_TOKEN}
    - {file: env.tier-agent,  key: CLAUDE_CODE_OAUTH_TOKEN}
  required: false

Necessary but not sufficient — read this before expecting archon to work

This routes the label. It does not conjure a value.

secrets_sync.py skips an entry entirely when no source value exists:

source_key = _first_usable(secrets, entry)
if source_key is None:
    if entry.required:
        missing.append(entry.label)
    continue        # not written at all

So until a token is provisioned into the CGP source, the key is emitted not at all — not emitted empty. That is the same blank-is-not-absent rule #2688 established: an empty secret is not a secret, so absent stays absent.

archon therefore behaves exactly as it does today until the value lands. No regression, and no fix yet either.

Sequencing after merge: mint the token (claude setup-token, in a real terminal), then export PMOVES_ROTATE_VALUE=... + make -C pmoves secrets-rotate KEY=CLAUDE_CODE_OAUTH_TOKEN (the env-var form keeps a bearer credential out of shell history and ps), then restart archon and re-run a workflow. Only after that is confirmed should CLAUDE_USE_GLOBAL_AUTH flip to false — flipping it first trips archon's exit(1) boot guard at index.ts:271-292.

Second fix, unavoidable and deliberate

The same sync emits min_length: 64 onto secret_key_base in the v1 manifest.

PR #2688 added that constraint to the registry, to v2, and to the sync logic — but never re-ran the sync. And secrets_sync.py:336 reads v1.

So the min-length gate shipped in #2688 has been inert on main: the constraint lived in v2 and in the tooling while the file the enforcer actually reads never carried it. A gate that could not fire.

It cannot be excluded here without hand-editing a machine-emitted file, which the pipeline forbids. So it ships with this change, explicitly rather than silently.

Gates

chit-manifest-register --check:  manifest complete: all registry labels present, no constraint drift
secrets-funnel (full chain):     0 errors, 12 warnings, env.tier-agent regenerated (46 entries)

Negative-tested, not trusted: injecting an unregistered label makes the check fail with Error 1 and would add: ZZ_NEGATIVE_TEST_KEY -> tier llm. The label was removed and the file restored byte-exact before commit.

Noted while verifying, not fixed here

The funnel audit already reports this whole bug class as a non-blocking WARN across seven tier files — for example:

[WARN] env.tier-agent: 24 keys in .example but missing from runtime:
       AGENT_ZERO_API_BASE, AGENT_ZERO_HEALTH_PATH, ..., AGENT_ZERO_MESSAGE_PATH....

AGENT_ZERO_MESSAGE_PATH in that list is the same var whose absence makes the supervisor proxy POST /tasks to /api_message, a route the runtime does not serve (it registers only /api/<path:path>, so the real route is /api/api_message). Separate lane; recorded here so it is not rediscovered.

🤖 Generated with Claude Code

https://claude.ai/code/session_01X9mpK1ZFjexjthZbvcb94f

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 6bbbf41f-e31f-4e9a-bd51-d8e18d6b663d

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

🔏 CHIT-aware change — control-body routing

This PR touches a CHIT-aware service (ports 8086/8087/8103/8106/8113/9224 surface). Before a Control-Body ACK:

• the diff (or PR body) should reference a CHIT signature trail — chit.signed.v1, a CHIT: trailer, or a make -C pmoves sign-trail entry;
• the chit-pr-audit-agent (.claude/agents/chit-pr-audit-agent.md) is the gate that grants/refuses ACK eligibility;
• signing quickstart: pmoves/docs/AGENTS/CHIT_SIGNING_TUTORIAL.md.

Advisory routing only — the blocking contract check is CHIT Contract.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: fb3db3f2b6

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".