refactor: remove env-leak consent model, enforce hard block on target repo .env

[Wirasm]

Summary

• Problem: The env-leak gate had a consent/bypass model (allow_env_keys, allow_target_repo_keys, --allow-env-keys) that could be overridden, weakening the security boundary
• Why it matters: Target repo .env secrets should never leak into Archon or provider subprocesses — no bypass should exist
• What changed: Removed the consent model end-to-end across scanner, config types, DB, API routes, CLI flags, Web UI, and all tests
• What did not change (scope boundary): Explicit Archon-managed env injection (.archon/config.yaml env:, DB-managed per-codebase env vars) still works. Boot-time stripCwdEnv() protection unchanged.

UX Journey

Before

  User                          Archon
  ────                          ──────
  registers repo ────────────▶  scans .env for sensitive keys
                                ⚠️ "Found ANTHROPIC_API_KEY"
                                offers consent: --allow-env-keys / UI checkbox / config bypass
  clicks "Allow" ────────────▶  sets allow_env_keys=true in DB
                                ✅ repo registered (keys leak into subprocesses)

After

  User                          Archon
  ────                          ──────
  registers repo ────────────▶  scans .env for sensitive keys
                                ❌ "Cannot use codebase — contains keys that will leak"
                                instructs user to remove/rename keys
  removes key from .env ─────▶  re-registers
                                ✅ repo registered (no ambient keys)

Label Snapshot

• Risk: risk: medium
• Size: size: L
• Scope: core, server, web, cli, config, tests
• Module: core:env-leak-scanner, core:clone, core:config, server:api, web:settings

Change Metadata

• Change type: security
• Primary scope: multi

Linked Issue

• Closes security: zero env leaks from managed repos into provider subprocesses #1135

Validation Evidence (required)

bun run validate  # All pass: type-check, lint, format, tests

• All 4 validation steps pass with zero errors
• 24 files changed, 89 insertions, 628 deletions (net removal)

Security Impact (required)

• New permissions/capabilities? No — this removes a permission bypass
• New external network calls? No
• Secrets/tokens handling changed? Yes — target repo .env secrets can no longer be consented to; they are unconditionally blocked
• File system access scope changed? No
• Risk mitigation: The change strictly tightens security. Users who previously relied on --allow-env-keys or the UI toggle must now remove sensitive keys from their repo's auto-loaded .env files.

Compatibility / Migration

• Backward compatible? No — users who relied on the consent bypass will need to remove sensitive keys from target repo .env files
• Config/env changes? Yes — allow_target_repo_keys in config.yaml is no longer recognized (silently ignored)
• Database migration needed? No — the allow_env_keys column remains in the schema (dead column, never read/written) for backwards compat

Human Verification (required)

• Verified scenarios: Full bun run validate passes (type-check, lint, format, tests)
• Edge cases checked: Existing DBs with allow_env_keys=true rows — column is ignored, repos will be blocked on next registration attempt
• What was not verified: End-to-end UI flow (server not started)

Side Effects / Blast Radius (required)

• Affected subsystems/workflows: Registration (clone/register), Web UI Settings page, CLI workflow run, server startup scan
• Potential unintended effects: Users with repos that have sensitive keys in .env and previously consented will be blocked on next interaction
• Guardrails/monitoring for early detection: Startup scan warns about repos that will be blocked; clear error messages tell users exactly what to fix

Rollback Plan (required)

• Fast rollback command/path: Revert the commit — the DB column still exists, old code reads it
• Feature flags or config toggles (if any): None — this is a hard policy change
• Observable failure symptoms: Users see "Cannot use codebase" errors when registering repos with sensitive .env keys

Risks and Mitigations

• Risk: Users who relied on consent bypass are blocked
  • Mitigation: Clear error message with exact fix instructions (remove key or rename file)

Summary by CodeRabbit

• Breaking Changes

  • Sensitive key detection is now mandatory for all repository registration — repositories containing sensitive keys in .env files are unconditionally rejected with no mechanism to bypass this check
  • Removed all UI controls and API endpoints for managing environment key permissions

• Updates

  • Error messaging clarified to reflect new enforcement behavior

[coderabbitai]

Caution

Review failed

Pull request was closed or merged during review

📝 Walkthrough

Walkthrough

Removes the env-leak consent model end-to-end: eliminates allow_env_keys from database schema, config types, API routes, CLI arguments, and UI surfaces. Registration and subprocess spawning now unconditionally block repositories with sensitive keys in auto-loaded .env files, with no bypass or override path.

Changes

Cohort / File(s)	Summary
Configuration & Types packages/core/src/config/config-types.ts, packages/core/src/config/config-loader.ts	Removed allow_target_repo_keys from GlobalConfig and RepoConfig, removed allowTargetRepoKeys from MergedConfig, and deleted bypass-warn-once tracking logic.
Database Schema & Codebases packages/core/src/db/adapters/sqlite.ts, packages/core/src/db/codebases.ts, packages/core/src/db/codebases.test.ts	Removed allow_env_keys column migration, dropped field from createCodebase signature, deleted updateCodebaseAllowEnvKeys function, and updated test fixtures.
Core Types & Exports packages/core/src/types/index.ts, packages/core/src/index.ts	Removed allow_env_keys property from Codebase interface and removed LeakErrorContext type re-export.
Env-Leak Scanner packages/core/src/utils/env-leak-scanner.ts, packages/core/src/utils/env-leak-scanner.test.ts	Removed LeakErrorContext type and context-driven remediation logic; EnvLeakError and formatLeakError now accept only LeakReport with unified, fixed error messaging.
Core Handlers packages/core/src/handlers/clone.ts, packages/core/src/handlers/clone.test.ts	Removed allowEnvKeys parameter from cloneRepository and registerRepository public APIs; removed per-call and config-based bypass logic during registration; always scan for sensitive keys without passing context.
CLI packages/cli/src/cli.ts, packages/cli/src/commands/workflow.ts	Removed --allow-env-keys flag from argument parser and help text; removed allowEnvKeys from WorkflowRunOptions interface and call to registerRepository.
API Routes & Schemas packages/server/src/routes/api.ts, packages/server/src/routes/schemas/codebase.schemas.ts, packages/server/src/routes/api.codebases.test.ts	Removed PATCH /api/codebases/{id} route that granted/revoked consent; removed updateCodebaseBodySchema; removed allowEnvKeys from addCodebaseBodySchema and codebaseSchema; updated handlers to not forward allowEnvKeys to registration functions.
Server Startup packages/server/src/index.ts	Removed conditional scan-skip logic when allowTargetRepoKeys was true; startup env-leak scan now always runs unconditionally in best-effort manner.
Web Frontend packages/web/src/lib/api.ts, packages/web/src/routes/SettingsPage.tsx	Removed allow_env_keys from CodebaseResponse; removed updateCodebase function for PATCH updates; removed allowEnvKeys parameter from addCodebase input type; removed env-key toggle UI and related state/mutations.
Documentation CLAUDE.md	Removed examples showing --allow-env-keys bypass during auto-registration; updated API docs to document "no bypass" behavior for sensitive keys in .env files.
Test Fixtures packages/core/src/handlers/command-handler.test.ts, packages/core/src/orchestrator/orchestrator-agent.test.ts, packages/core/src/orchestrator/orchestrator-isolation.test.ts, packages/core/src/orchestrator/orchestrator.test.ts	Removed allow_env_keys: false from mocked Codebase objects across test suites.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related issues

• security: zero env leaks from managed repos into provider subprocesses #1135 — Directly addresses the core requirement to remove the consent model and enforce unconditional env-leak blocking as a hard safety boundary rather than a user-overridable gate.

Possibly related PRs

• Release 0.3.0 #985 — Removed/reverts the env-leak consent plumbing (allow_env_keys, CLI flag, API routes, config types, scanner context-driven messaging) that was added in that PR.
• fix(sqlite): add allow_env_keys column to codebases schema + migration #988 — Related at the database schema level; that PR ensures the allow_env_keys column exists and is migrated, while this PR ceases to read/write it and marks it as deprecated.
• fix(env-leak-gate): skip pre-spawn scan for unregistered cwd paths (#991) #992 — Related through shared env-leak scanning behavior; both PRs modify when/how the scan is triggered and whether bypass logic is applied.

Suggested reviewers

• coleam00

---

🐰 A rabbit hops through code with glee,
No more consent, now it's "refuse to be"—
Safe env keys locked away tight,
Secrets stay put, oh what a delight!
No more bypass, no more play,
Security wins the Archon way! 🔐

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 38.89% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'refactor: remove env-leak consent model, enforce hard block on target repo .env' accurately summarizes the primary change of removing the consent/bypass mechanism and enforcing unconditional blocking of target repo env keys.
Description check	✅ Passed	The PR description comprehensively covers all required template sections: problem/rationale, UX journey before/after, change metadata, validation evidence (bun run validate passes), security impact (removes bypass), compatibility notes (not backward compatible), and rollback plan.
Linked Issues check	✅ Passed	All changes align with issue #1135 requirements: removed consent primitives (allow_env_keys, allow_target_repo_keys, --allow-env-keys) across DB, config, API, CLI, and Web UI; enforced hard blocking of target repo .env; maintained explicit Archon-managed env injection.
Out of Scope Changes check	✅ Passed	All changes are in-scope: removal of consent model from scanner, config, DB, API routes, CLI, Web UI, and test fixtures. No unrelated refactoring, feature additions, or tangential modifications detected.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feature/remove-env-consent-model

---

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 and usage tips.}

[Wirasm]

Closing — wrong approach. Blocking repos is the wrong primitive. The correct fix is to prevent Bun from auto-loading target repo .env into subprocesses, not to refuse repos that have sensitive keys. Will re-implement with the right architecture.