Provider config-dir overrides (CODEX_HOME/CLAUDE_CONFIG_DIR) no longer reach agent panes after the #204 env scrub #211

New issue

Closed

opened 2026-07-23 01:35:37 +02:00 by dominik.polakovics · 1 comment

dominik.polakovics commented

2026-07-23 01:35:37 +02:00

Owner

Context

#204 scrubs the lab service environment from spawned tmux sessions: panes now receive only the explicit spawnEnv allow-list plus a PATH/HOME/TERM/locale baseline.

Before the scrub, an operator who set CODEX_HOME or CLAUDE_CONFIG_DIR on the lab unit got that override in every pane via full-env inheritance — the same accidental channel that leaked EnvironmentFile secrets. After the scrub, the lab-side code still honors the override (internal/provider/codex/codex.go codexHomeDir, internal/provider/claudecode/logout.go credentialsPath) but the CLI running inside the pane no longer sees it and falls back to $HOME/.codex / $HOME/.claude — a split-brain: lab seeds config and checks credentials in one directory while the agent CLI uses another.

Impact today

None. No deployment sets these vars (unit env, nix module, and test rigs all clear — compat/logout tests exec the CLI directly, not via tmux). This is a latent seam, not a live regression.

What to build

If the override is a supported operator seam, it must reach panes deliberately: the provider adds its config-dir var to its spawn extraEnv (and login-session env) when set — spawnEnv-layer work per the #201/#202 boundary, not a tmuxx baseline addition. Alternatively, declare the override unsupported under lab and document that.

Blocked by

None.

## Context #204 scrubs the lab service environment from spawned tmux sessions: panes now receive only the explicit spawnEnv allow-list plus a PATH/HOME/TERM/locale baseline. Before the scrub, an operator who set `CODEX_HOME` or `CLAUDE_CONFIG_DIR` on the lab unit got that override in every pane via full-env inheritance — the same accidental channel that leaked EnvironmentFile secrets. After the scrub, the lab-side code still honors the override (`internal/provider/codex/codex.go` codexHomeDir, `internal/provider/claudecode/logout.go` credentialsPath) but the CLI running inside the pane no longer sees it and falls back to `$HOME/.codex` / `$HOME/.claude` — a split-brain: lab seeds config and checks credentials in one directory while the agent CLI uses another. ## Impact today None. No deployment sets these vars (unit env, nix module, and test rigs all clear — compat/logout tests exec the CLI directly, not via tmux). This is a latent seam, not a live regression. ## What to build If the override is a supported operator seam, it must reach panes deliberately: the provider adds its config-dir var to its spawn extraEnv (and login-session env) when set — spawnEnv-layer work per the #201/#202 boundary, not a tmuxx baseline addition. Alternatively, declare the override unsupported under lab and document that. ## Blocked by None.

dominik.polakovics added the

needs-triage

label

2026-07-23 01:35:37 +02:00

dominik.polakovics referenced this issue

2026-07-23 01:36:15 +02:00

feat(tmuxx): scrub inherited lab service env from spawned sessions #212

dominik.polakovics referenced this issue

2026-07-23 03:26:50 +02:00

feat(tmuxx): scrub inherited lab service env from spawned sessions #212

dominik.polakovics commented

2026-07-25 18:10:29 +02:00

Author

Owner

This was generated by AI during triage.

Triage decision: wontfix

The report is accurate — verified by code trace: the tmuxx baseline scrub (#204) stops CODEX_HOME/CLAUDE_CONFIG_DIR from reaching panes, while the lab-side resolvers (codexHomeDir, credentialsPath, both credauthority pokes) still honor them. The exposure is narrower than the title suggests, though: regular agent panes were never affected (InjectCredentials pins the config-dir var explicitly to the instance home), so the only split-brain surface is the host-mode login session, which is spawned with no extra env — a login would write credentials to ~/.codex / ~/.claude while lab reads the overridden master dir.

Why we're not actioning it:

Zero impact today, as the issue itself established: no deployment sets these vars anywhere.
The containerized login flow (#206) resolves this by construction for the primary path: a login container has no env inheritance at all — lab resolves the master store with its own override-aware resolvers, mounts it rw, and pins the config-dir var explicitly inside the container. Both halves derive from the same resolver, so no split-brain is possible.
What remains after #206 is only the break-glass host-mode login path. The master-store env override is declared unsupported there — wiring an override into a fallback path nobody configures isn't worth the seam it keeps alive.

If a real deployment ever needs a relocated master store under host mode, this can be reopened with that concrete case.

> *This was generated by AI during triage.* ## Triage decision: wontfix The report is accurate — verified by code trace: the tmuxx baseline scrub (#204) stops `CODEX_HOME`/`CLAUDE_CONFIG_DIR` from reaching panes, while the lab-side resolvers (`codexHomeDir`, `credentialsPath`, both credauthority pokes) still honor them. The exposure is narrower than the title suggests, though: regular agent panes were never affected (`InjectCredentials` pins the config-dir var explicitly to the instance home), so the only split-brain surface is the **host-mode login session**, which is spawned with no extra env — a login would write credentials to `~/.codex` / `~/.claude` while lab reads the overridden master dir. Why we're not actioning it: - **Zero impact today**, as the issue itself established: no deployment sets these vars anywhere. - **The containerized login flow (#206) resolves this by construction** for the primary path: a login container has no env inheritance at all — lab resolves the master store with its own override-aware resolvers, mounts it rw, and pins the config-dir var explicitly inside the container. Both halves derive from the same resolver, so no split-brain is possible. - What remains after #206 is only the **break-glass host-mode login** path. The master-store env override is declared **unsupported** there — wiring an override into a fallback path nobody configures isn't worth the seam it keeps alive. If a real deployment ever needs a relocated master store under host mode, this can be reopened with that concrete case.

dominik.polakovics

2026-07-25 18:10:37 +02:00