Scrub inherited environment from host-mode agent panes #204

Closed
opened 2026-07-22 11:43:54 +02:00 by dominik.polakovics · 1 comment

What to build

tmux panes currently inherit the lab process's entire environment because the tmux server is a child of the service — so anything in the unit's EnvironmentFile (e.g. a LAB_DB Postgres DSN with password) is readable by every agent. Fix at the tmux seam: spawned sessions must receive only the explicit allow-listed env (the current -e set: cred env, LAB_URL/LAB_TOKEN, git author vars) plus a minimal baseline (PATH, HOME, TERM, locale). Host mode survives through the container migration, so this matters independently of the container runner.

Acceptance criteria

  • A variable present in the lab process env but not in spawnEnv (e.g. LAB_DB) is NOT visible in a spawned agent pane's environment
  • Agent CLIs still function (PATH/HOME/TERM preserved); login sessions unaffected
  • Regression test asserts the scrub at the tmuxx/session-runner layer

Blocked by

None - can start immediately

## What to build tmux panes currently inherit the lab process's entire environment because the tmux server is a child of the service — so anything in the unit's EnvironmentFile (e.g. a `LAB_DB` Postgres DSN with password) is readable by every agent. Fix at the tmux seam: spawned sessions must receive only the explicit allow-listed env (the current `-e` set: cred env, LAB_URL/LAB_TOKEN, git author vars) plus a minimal baseline (PATH, HOME, TERM, locale). Host mode survives through the container migration, so this matters independently of the container runner. ## Acceptance criteria - [ ] A variable present in the lab process env but not in spawnEnv (e.g. LAB_DB) is NOT visible in a spawned agent pane's environment - [ ] Agent CLIs still function (PATH/HOME/TERM preserved); login sessions unaffected - [ ] Regression test asserts the scrub at the tmuxx/session-runner layer ## Blocked by None - can start immediately
Author
Owner

This was generated by AI during triage.

Agent Brief

Category: enhancement
Summary: Spawned tmux panes must receive only the allow-listed spawn env plus a minimal baseline — not the lab service's full inherited environment.

The issue body's "What to build" and acceptance-criteria checklist are the authoritative spec (grilled 2026-07-22). This brief adds the interface map and scope fences.

Current behavior:
The tmux server is a child of the lab service, so every pane inherits the unit's entire environment — including EnvironmentFile secrets such as a LAB_DB Postgres DSN with password. The -e flags emitted by the session-args builder in the tmux wrapper package only add the explicit set (spawnEnv: cred env, LAB_URL/LAB_TOKEN, git author vars); nothing subtracts the inherited remainder.

Desired behavior:
A spawned session's environment is exactly: the explicit spawnEnv allow-list, plus a minimal baseline (PATH, HOME, TERM, locale). Any other variable present in the lab process env is absent from the pane. This must hold for regular agent runs and for login sessions, and agent CLIs must keep working. State the scrub as a property of the tmux/session-runner seam — the mechanism (env-clearing wrapper around the pane command, tmux environment controls, etc.) is the agent's choice.

Key interfaces:

  • The tmux wrapper's session creation (Tmux.Start / its session-args builder) — the seam where the scrub belongs, composing with the existing prlimit pane wrapper.
  • spawnEnv — stays the single source of truth for the allow-list; this issue must not grow it.

Acceptance criteria: the checklist in the issue body — the regression test asserting a planted lab-process-only variable is invisible in a pane is the core deliverable.

Out of scope:

  • The container runner (#205) — containers get env isolation from explicit -e anyway; this issue is the host-mode fix, which must survive independently since host mode remains break-glass after the migration.
  • Changing what spawnEnv contains (that set is #201/#202 territory).
> *This was generated by AI during triage.* ## Agent Brief **Category:** enhancement **Summary:** Spawned tmux panes must receive only the allow-listed spawn env plus a minimal baseline — not the lab service's full inherited environment. The issue body's "What to build" and acceptance-criteria checklist are the authoritative spec (grilled 2026-07-22). This brief adds the interface map and scope fences. **Current behavior:** The tmux server is a child of the lab service, so every pane inherits the unit's entire environment — including EnvironmentFile secrets such as a `LAB_DB` Postgres DSN with password. The `-e` flags emitted by the session-args builder in the tmux wrapper package only *add* the explicit set (`spawnEnv`: cred env, LAB_URL/LAB_TOKEN, git author vars); nothing subtracts the inherited remainder. **Desired behavior:** A spawned session's environment is exactly: the explicit `spawnEnv` allow-list, plus a minimal baseline (PATH, HOME, TERM, locale). Any other variable present in the lab process env is absent from the pane. This must hold for regular agent runs and for login sessions, and agent CLIs must keep working. State the scrub as a property of the tmux/session-runner seam — the mechanism (env-clearing wrapper around the pane command, tmux environment controls, etc.) is the agent's choice. **Key interfaces:** - The tmux wrapper's session creation (`Tmux.Start` / its session-args builder) — the seam where the scrub belongs, composing with the existing prlimit pane wrapper. - `spawnEnv` — stays the single source of truth for the allow-list; this issue must not grow it. **Acceptance criteria:** the checklist in the issue body — the regression test asserting a planted lab-process-only variable is invisible in a pane is the core deliverable. **Out of scope:** - The container runner (#205) — containers get env isolation from explicit `-e` anyway; this issue is the host-mode fix, which must survive independently since host mode remains break-glass after the migration. - Changing what `spawnEnv` contains (that set is #201/#202 territory).
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Cloonar/coding-lab#204
No description provided.