You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
msb: kit startup commands (incl. background daemons) get only their own kit's environment[], so daemon-launched agents lose other kits' config #515
On msb, a kit's startup command runs with only its own kit's environment[] (_acq_msb_run_commands threads _acq_msb_collect_kit_env_into for that one spec onto msb exec -e). Interactive sessions get every kit's env, because acq replays the persisted /var/lib/acq/kit-env, but long-lived processes started by a kit's background: true startup command don't.
This matters for daemons that launch agents. The Paseo kit starts paseo daemon from its own startup command, so every agent Paseo spawns inherits only the Paseo kit's env. Any other kit's agent configuration is silently missing. With a team kit that sets OPENCODE_CONFIG (team instructions plus a default-deny glab/gh permission layer), Paseo-launched OpenCode agents run without team instructions and without those permission rules, while GITLAB_TOKEN/GITHUB_TOKEN are still present in the daemon's env.
Reproduction
acq main@187aa57, msb 0.7.3, ACQ_EXTRA_KITS = a team kit declaring environment: {OPENCODE_CONFIG: ..., GITLAB_HOST: ...} + the patterns Paseo kit.
acq exec<sandbox> -- sh -c 'env | grep -c ^OPENCODE_CONFIG='# 1: session has it
acq exec<sandbox> -- sh -c 'p=$(pgrep -f "paseo daemon" | tail -1); tr "\0" "\n" < /proc/$p/environ | grep -c ^OPENCODE_CONFIG='# 0: daemon lacks it
The daemon's env has the Paseo kit's own PASEO_* vars plus secrets (GITLAB_TOKEN, GITHUB_TOKEN, USAI_API_KEY), but none of the team kit's environment[] (OPENCODE_CONFIG, OPENCODE_TUI_CONFIG, GITLAB_HOST, TERMINFO_DIRS). opencode debug config run with the daemon's env shows no team instructions and no glab/gh permission rules.
Expected
Kit environment[] is guest-wide configuration, so every kit command, and especially background: true daemons, should see the same merged env that sessions replay from /var/lib/acq/kit-env, with the same last-value-wins order.
Suggested fix
Thread the merged, persisted kit env (not just the owning spec's) onto startup msb exec calls, at least for background: true commands. Kits then don't each need to source /var/lib/acq/kit-env themselves.
Impact
Silent: nothing fails, and terminal sessions look correct, so smoke tests pass. Security-relevant whenever a kit's env carries permission or policy config for agents that a daemon kit launches.
AI-assisted (OpenCode). The fix (#519) has been live-verified against real msb 0.7.4 — see the detailed comment on that PR. Summary: reproduced this issue's own repro mechanism (/proc/<daemon-pid>/environ) with two real test kits (one declaring environment[], one starting a background: true daemon), confirmed the daemon now inherits the other kit's env in both apply orders, and separately confirmed the security-critical guard-isolation fix (one kit's GIT_TERMINAL_PROMPT override doesn't leak into another kit's daemon) also holds in both orders. No live-vs-stub discrepancy found.
Activity
docs(isolation): GitHub over HTTPS, daemon env scope, multi-repo writ…
wz-gsa commentedon Oct 1, 2026
AI-assisted (OpenCode). The fix (#519) has been live-verified against real
msb 0.7.4— see the detailed comment on that PR. Summary: reproduced this issue's own repro mechanism (/proc/<daemon-pid>/environ) with two real test kits (one declaringenvironment[], one starting abackground: truedaemon), confirmed the daemon now inherits the other kit's env in both apply orders, and separately confirmed the security-critical guard-isolation fix (one kit'sGIT_TERMINAL_PROMPToverride doesn't leak into another kit's daemon) also holds in both orders. No live-vs-stub discrepancy found.fix(msb): thread the merged kit env onto kit lifecycle commands (#519)