[lilyshen0722]

What

Removes the anthropic-api-key remoteRef from the api-keys ExternalSecret. It's the last chart reference to the Anthropic credential: direct Anthropic routes were removed from the litellm config under D76, and the litellm deployment template no longer references ANTHROPIC_API_KEY (grep is clean on main). The credential is inert — nothing routes to it.

⚠️ Staged for post-launch — do not press/deploy mid-freeze

Opening now so it's ready, per the ledger. The sequence is strict:

1. Merge this
2. Deploy
3. Then disable the GCP SM versions of commonly-dev-anthropic-api-key (manual, SRE)

Disabling the SM secret before this deploys would error the whole api-keys ExternalSecret sync — ESO rejects the ExternalSecret when any referenced remote key is missing, which would take down every other key (openrouter, deepseek, gemini, …) on the next 1h sync. So the SM disable is the last step, never the first.

Ledger: D76.

🤖 Generated with Claude Code

https://claude.ai/code/session_01MDs9DS64Df3HsKsCHiKBWN

[coderabbitai]

No actionable comments were generated in the recent review.

Recent review info

Run configuration

• Source mode: Auto
• Repository: Team-Commonly/commonly
• Branch: sre-anthropic-cred-drop
• File: .coderabbit.yaml
• Commit: ff61c8a
• Layers: Repository YAML
• Review profile: QUIET
• Plan: Advanced
• Run ID: 55bb594e-b7b1-4625-81af-9b55980f7477

Commits

Reviewing files that changed from the base of the PR and between c0c0ab2 and ff61c8a.

Files selected for processing: 1

• k8s/helm/commonly/templates/secrets/api-keys.yaml

Files with no reviewable changes: 1

• k8s/helm/commonly/templates/secrets/api-keys.yaml

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 5 remain after this review.

Walkthrough

The Helm chart no longer includes the Anthropic API key in the api-keys ExternalSecret.

Changes: Anthropic API key mapping

Layer / File(s)	Summary
Remove the API key mapping k8s/helm/commonly/templates/secrets/api-keys.yaml	The ExternalSecret no longer maps the remote anthropic-api-key secret.

Priority: Low

Estimated code review effort: 1 (Trivial) | ~3 minutes

Change: Other

Possibly related PRs

• Team-Commonly/commonly#2704: This PR removes the remaining Anthropic API key reference after PR #2704 removed the direct Anthropic LiteLLM routes and runtime consumers.

Merge Risk: Minimal · up to ff61c

The change is mergeable. Deploy the chart before disabling the remote secret, as planned.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title clearly identifies the removal of the unused Anthropic API key remote reference and matches the changeset.
Description check		The description directly explains the removed reference, its dependency on the LiteLLM changes, and the required deployment sequence.
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Finishing Touches

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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

[lilyshen0722]

Otto gate at ff61c8a.

Nothing on main reads anthropic-api-key from the api-keys Secret.

• Chart templates: apart from this ExternalSecret entry, no template names the key. There is no secretKeyRef to it, and no envFrom mounts api-keys whole, so no pod can pick the key up implicitly.
• Backend direct reads: agentProvisionerServiceK8s calls readNamespacedSecret('api-keys'), but it only decodes the openai-codex-* keys. The pod specs it builds map clawdbot-gateway-token, brave-api-key, firecrawl-api-key, deepgram-api-key and commonly-bot-runtime-token. No key name is assembled dynamically.
• ANTHROPIC_API_KEY in code: managedAgentsAdapter, registry/detect.ts and workers/agent-runtime read it from process.env. No template on main sets that variable, so the cluster backend already runs without it, and this PR doesn't change any pod's env.
• Other charts: the commonly-bot test already asserts that chart has no Anthropic key. LiteLLM's config notes that its direct Anthropic routes were removed.

The rest of the ExternalSecret still syncs. I rendered templates/secrets/api-keys.yaml at main and at this head with the defaults, and with errorTracking and hostedSandbox turned on. The only difference is these three lines; every other data entry is unchanged. It also renders with values-dev.yaml. The template is unchanged on main since this PR's base, so the merge is clean. With creationPolicy: Owner, ESO drops the key from the Secret on its next refresh (refreshInterval: 1h).

The order matters. The template's own comment says ESO rejects the whole ExternalSecret when any referenced remote key is missing. So before SRE disables the Secret Manager versions, the deployed ExternalSecret has to report synced at the generation without this entry. Disabling them earlier would stop every key in api-keys from refreshing, not just this one.

Non-blocking, stale text left behind:

• The header of backend/services/managedAgentsAdapter.ts says the ESO mapping is wired for the backend pod. It isn't.
• k8s/QUICK_START.md (line 94) still tells self-hosters to create the Anthropic secret, and k8s/IMPLEMENTATION_STATUS.md still lists it.

Written by Otto, a Commonly agent — https://commonly.me/v2/pods/6a920d3eb08dee6c42a81bfc

GATE: PASS