fix(provisioner): Forensic #145 — preserve workspace-authored SCM token, strip only operator/global bleed #2320

Merged

claude-ceo-assistant merged 1 commits from fix/forensic145-preserve-workspace-scm-token into main 2026-06-05 21:57:59 +00:00

Conversation 0 Commits 1 Files Changed 8

+286 -37

claude-ceo-assistant commented 2026-06-05 21:44:11 +00:00

Owner

Copy Link

Copy Source

Forensic #145 guard: preserve workspace-authored SCM token, strip only operator/global bleed

Root cause (confirmed by live ground-truth probe)

Codex reviewer agents (and any tenant agent) silently lost their GITEA_TOKEN inside the container: /configs/secrets.d/ held only the global CODEX_AUTH_JSON, $GITEA_TOKEN was absent, and a Gitea whoami returned 401/404 → reviewers could exec but could not post reviews, stalling the 2nd-approval path.

The token exists in the CP as a workspace-scoped secret, and CP-side delivery (cp#444) is correct. But CPProvisioner.Start() (the Forensic #145 guard, workspace-server/internal/provisioner/cp_provisioner.go) strips every key in scmWriteTokenKeys (GITEA_TOKEN, …) by key-name alone, with no provenance awareness — so it dropped the workspace-authored token before it ever reached the CP delivery layer.

The guard's real and still-valid purpose (per its own comment) is to stop operator / persona-merged (global-scoped) SCM-write tokens from bleeding into a tenant container. It was never meant to block a workspace token the org admin deliberately set for that workspace's reviewer.

Fix (provenance-aware, fail-safe — the security intent is preserved, not removed)

• loadWorkspaceSecrets already computed a globalKeys provenance set and deletes a key from it when a workspace secret overrides it. This PR adds the positive mirror: a workspaceKeys set of keys sourced from the workspace_secrets table.
• That set is threaded through prepareProvisionContext → WorkspaceConfig.WorkspaceSecretKeys (carried by both Docker- and CP-mode configs).
• The guard (extracted to the unit-testable buildCPTenantEnv) now strips an SCM-write token unless it is positively in WorkspaceSecretKeys. Operator/global and persona/mutator-injected tokens are NOT in that set → still stripped. Nil map → strips everything (fail-safe) — a missing provenance map can never leak.

Security invariants (each a passing table-test row in TestBuildCPTenantEnv_ForensicGuardProvenance)

1. SCM token only in global_secrets → STRIPPED
2. SCM token persona/mutator-injected (in env, not in workspace provenance) → STRIPPED (the exact bleed the guard exists for)
3. SCM token authored via workspace_secrets → PRESERVED
4. WorkspaceSecretKeys == nil → all 6 SCM keys STRIPPED (fail-safe)
5. non-SCM keys unaffected

Plus TestLoadWorkspaceSecrets_WorkspaceKeysProvenance (workspace key lands in workspaceKeys, removed from globalKeys; operator-only key stays global) and TestBuildCPTenantEnv_AdminTokenInjected.

Scope

CP/EC2 path only (where the affected codex reviewers run). Docker-mode buildContainerEnv is unchanged (it stays strictly more-stripping → no security regression); symmetric Docker treatment is a noted follow-up, not needed for this fix.

Verification

go build ./..., go vet ./... clean. go test ./internal/provisioner/... ./internal/handlers/... green. Integration-tag failures are pre-existing (no Postgres locally; CI provides one). gofmt clean on edited files.

---

SOP checklist

• comprehensive-testing — 5 security invariants + provenance + admin-token injection, table-tested; regression-proven (strip/preserve both asserted).
• root-cause — confirmed by live container probe (secrets.d listing + whoami HTTP), traced to the exact strip site; not a symptom patch.
• five-axis-review — correctness/security/failure-mode/blast-radius/tests reviewed; security axis is the crux (fail-safe on nil, persona-bleed still stripped).
• no-backwards-compat-shim — provenance is additive; zero-value behavior identical for every existing provider; no compat shim.
• memory-consulted — aligns with the codex GITEA_TOKEN-delivery history (cp#444 delivery correct; this is the upstream strip).
• local-postgres-e2e — N/A: change is in the pure env-build path; covered by unit tests with sqlmock. Integration suite runs in CI with Postgres.
• staging-smoke — to be exercised by reprovisioning the reviewer workspaces onto the deployed fix (the real artifact: whoami=200 + a posted review).

🤖 Generated with Claude Code

## Forensic #145 guard: preserve workspace-authored SCM token, strip only operator/global bleed ### Root cause (confirmed by live ground-truth probe) Codex reviewer agents (and any tenant agent) silently lost their `GITEA_TOKEN` inside the container: `/configs/secrets.d/` held only the *global* `CODEX_AUTH_JSON`, `$GITEA_TOKEN` was absent, and a Gitea `whoami` returned 401/404 → **reviewers could exec but could not post reviews**, stalling the 2nd-approval path. The token *exists* in the CP as a **workspace-scoped** secret, and CP-side delivery (cp#444) is correct. But `CPProvisioner.Start()` (the Forensic #145 guard, `workspace-server/internal/provisioner/cp_provisioner.go`) strips **every** key in `scmWriteTokenKeys` (`GITEA_TOKEN`, …) **by key-name alone, with no provenance awareness** — so it dropped the workspace-authored token before it ever reached the CP delivery layer. The guard's real and still-valid purpose (per its own comment) is to stop **operator / persona-merged (global-scoped)** SCM-write tokens from bleeding into a tenant container. It was never meant to block a workspace token the org admin deliberately set for that workspace's reviewer. ### Fix (provenance-aware, fail-safe — the security intent is preserved, not removed) - `loadWorkspaceSecrets` already computed a `globalKeys` provenance set and `delete`s a key from it when a workspace secret overrides it. This PR adds the **positive mirror**: a `workspaceKeys` set of keys sourced from the `workspace_secrets` table. - That set is threaded through `prepareProvisionContext` → `WorkspaceConfig.WorkspaceSecretKeys` (carried by both Docker- and CP-mode configs). - The guard (extracted to the unit-testable `buildCPTenantEnv`) now strips an SCM-write token **unless it is positively in `WorkspaceSecretKeys`**. Operator/global **and** persona/mutator-injected tokens are NOT in that set → still stripped. **Nil map → strips everything (fail-safe)** — a missing provenance map can never leak. ### Security invariants (each a passing table-test row in `TestBuildCPTenantEnv_ForensicGuardProvenance`) 1. SCM token only in `global_secrets` → **STRIPPED** 2. SCM token persona/mutator-injected (in env, not in workspace provenance) → **STRIPPED** (the exact bleed the guard exists for) 3. SCM token authored via `workspace_secrets` → **PRESERVED** 4. `WorkspaceSecretKeys == nil` → **all 6 SCM keys STRIPPED** (fail-safe) 5. non-SCM keys unaffected Plus `TestLoadWorkspaceSecrets_WorkspaceKeysProvenance` (workspace key lands in `workspaceKeys`, removed from `globalKeys`; operator-only key stays global) and `TestBuildCPTenantEnv_AdminTokenInjected`. ### Scope CP/EC2 path only (where the affected codex reviewers run). Docker-mode `buildContainerEnv` is unchanged (it stays strictly more-stripping → no security regression); symmetric Docker treatment is a noted follow-up, not needed for this fix. ### Verification `go build ./...`, `go vet ./...` clean. `go test ./internal/provisioner/... ./internal/handlers/...` green. Integration-tag failures are pre-existing (no Postgres locally; CI provides one). gofmt clean on edited files. --- ### SOP checklist - [x] **comprehensive-testing** — 5 security invariants + provenance + admin-token injection, table-tested; regression-proven (strip/preserve both asserted). - [x] **root-cause** — confirmed by live container probe (`secrets.d` listing + `whoami` HTTP), traced to the exact strip site; not a symptom patch. - [x] **five-axis-review** — correctness/security/failure-mode/blast-radius/tests reviewed; security axis is the crux (fail-safe on nil, persona-bleed still stripped). - [x] **no-backwards-compat-shim** — provenance is additive; zero-value behavior identical for every existing provider; no compat shim. - [x] **memory-consulted** — aligns with the codex GITEA_TOKEN-delivery history (cp#444 delivery correct; this is the upstream strip). - [ ] **local-postgres-e2e** — N/A: change is in the pure env-build path; covered by unit tests with sqlmock. Integration suite runs in CI with Postgres. - [ ] **staging-smoke** — to be exercised by reprovisioning the reviewer workspaces onto the deployed fix (the real artifact: `whoami`=200 + a posted review). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

claude-ceo-assistant added 1 commit 2026-06-05 21:44:12 +00:00

fix(forensic145): exempt workspace-authored SCM tokens from tenant-env strip ... 7ca572f220

The forensic #145 guard in CPProvisioner.Start stripped EVERY env key
matching isSCMWriteTokenKey (GITEA_TOKEN, GITHUB_TOKEN, …) by key-name
only, with no provenance awareness. That wrongly stripped a GITEA_TOKEN an
org admin deliberately set as a workspace_secret — the intended delivery
channel for a codex reviewer agent — so the agent never received it and
could not post Gitea reviews (whoami 401/404).

The guard's REAL purpose is to stop operator/persona-merged (global-scoped)
SCM-write tokens from bleeding into tenant containers, NOT to block
user-authored workspace tokens.

Change:
- loadWorkspaceSecrets now also returns a positive workspaceKeys set
  (keys sourced from the workspace_secrets table), alongside the existing
  globalKeys operator-bleed provenance.
- WorkspaceConfig gains WorkspaceSecretKeys, threaded through
  buildProvisionerConfig / prepareProvisionContext to both Docker- and
  CP-mode configs.
- The CP guard (extracted to buildCPTenantEnv for testability) strips an
  SCM-write token UNLESS it is positively workspace-authored. A nil
  provenance map fails safe (strips all).

Security invariants encoded as table tests:
  1. global_secrets-only token  → STRIPPED
  2. persona/mutator-injected   → STRIPPED (the exact bleed the guard exists for)
  3. workspace_secrets-authored → PRESERVED
  4. nil WorkspaceSecretKeys    → ALL STRIPPED (fail-safe)
  5. non-SCM keys               → pass through unchanged
Plus a loadWorkspaceSecrets test asserting a workspace_secrets-sourced key
lands in workspaceKeys and is removed from globalKeys.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

claude-ceo-assistant merged commit 1955fdd0e5 into main 2026-06-05 21:57:59 +00:00

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

Clear labels

area/ci

CI/CD pipeline issues

do-not-auto-merge

Opt out of autonomous merge-queue merging

kind/infrastructure

Infrastructure-related issues

merge-queue

Ready for serialized Gitea merge queue

merge-queue-hold

Temporarily hold PR in merge queue

platform/go

Go platform test issues

release-blocker

Blocks the staging→main promotion / a release

release-test

security

test-label-sre

tier:high

High risk per dev-sop §SOP-6 — ceo only, 24h cooldown

tier:low

Low risk per dev-sop §SOP-6 — engineers/managers/ceo can approve

tier:medium

Medium risk per dev-sop §SOP-6 — managers/ceo can approve

triage-test

test

wip

Work in progress — do not auto-merge

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

agent-dev-a agent-dev-b agent-pm agent-researcher agent-reviewer agent-reviewer-1 agent-reviewer-cr2 app-fe (Molecule AI · app-fe) app-lead (Molecule AI · app-lead) app-qa (Molecule AI · app-qa) claude-ceo-assistant claude-ci-reader claude-status-reaper core-be (Molecule AI · core-be) core-devops (Molecule AI · core-devops) core-fe (Molecule AI · core-fe) core-lead (Molecule AI · core-lead) core-offsec (Molecule AI · core-offsec) core-qa (Molecule AI · core-qa) core-security (Molecule AI · core-security) core-uiux (Molecule AI · core-uiux) cp-be (Molecule AI · cp-be) cp-lead (Molecule AI · cp-lead) cp-qa (Molecule AI · cp-qa) cp-security (Molecule AI · cp-security) cui (Zhanlin Cui) dev-lead (Molecule AI · dev-lead) devops-engineer documentation-specialist (Molecule AI · documentation-specialist) fullstack-engineer (Molecule AI · fullstack-engineer) hongming hongming-ceo-delegated hongming-codex-laptop hongming-kimi-laptop hongming-pc2 infra-lead (Molecule AI · infra-lead) infra-runtime-be (Molecule AI · infra-runtime-be) infra-sre (Molecule AI · infra-sre) integration-tester (Molecule AI · integration-tester) mc-drift-bot molecule-code-reviewer plugin-dev (Molecule AI · plugin-dev) pm publish-runtime-bot pypi-publisher (Molecule AI PyPI Publisher (RFC#596)) release-manager (Molecule AI · release-manager) sdk-dev (Molecule AI · sdk-dev) sdk-lead (Molecule AI · sdk-lead) sop-drift-bot sop-tier-bot (SOP Tier-Check Bot) technical-writer (Molecule AI · technical-writer) triage-operator (Molecule AI · triage-operator)

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: molecule-ai/molecule-core#2320