Reported by a peer workspace's architect (owner-worded, 2026-09-17), deduped against the env-hygiene family (#1219/#1626/#1627 cover inheritance; this is distinct) and mechanism-verified in code before filing.
Mechanism
session-manager.ts:281 serializes the shellper's spawn config — including the full env map — into a JSON blob passed as argv[2] of every shellper-main.js process (shellper-main.ts:7 documents the contract). Any secret exported in the user's login shell (reporter's case: a cloud-provider credential variable; name withheld — public repo) therefore appears in the command line of every shellper.
Verification note from the field: ps -o command= shows 0 matches — that's truncation; ps -p <pid> -ww -o command= shows the variable in argv on every shellper sampled.
Severity: hygiene, not incident (deliberately calibrated down by the reporting owner)
Not an access-control hole on a single-user dev machine: same-user processes can read the env regardless, and the other-account processes on typical macOS hosts are service daemons. The real, demonstrated risk is accidental disclosure: argv is what gets pasted into bug reports, logs, and agent transcripts — in the reporting workspace, a routine ps during a hung-process diagnosis pulled the secret into an agent's conversation context. ps output travels; env mostly doesn't. Weight increases in any CI or shared-host context running the same path.
Fix shape (cheap, contained)
Stop putting env (and ideally the whole config) in argv: pass it via the child's process environment, a pipe/stdin, or an inherited fd — the shellper already has a socket handshake (HELLO/WELCOME) that could carry config equally well. Nothing else changes; argv exposure disappears. Note the RECONNECT path already sends spawn config over the socket (msg.env at shellper-process.ts:495), so the socket-borne shape has precedent in the same file.
Related-not-duplicate: #1219/#1626/#1627 (inherited-env contamination — different defect, same hygiene family).
Reported by a peer workspace's architect (owner-worded, 2026-09-17), deduped against the env-hygiene family (#1219/#1626/#1627 cover inheritance; this is distinct) and mechanism-verified in code before filing.
Mechanism
session-manager.ts:281serializes the shellper's spawn config — including the fullenvmap — into a JSON blob passed asargv[2]of everyshellper-main.jsprocess (shellper-main.ts:7documents the contract). Any secret exported in the user's login shell (reporter's case: a cloud-provider credential variable; name withheld — public repo) therefore appears in the command line of every shellper.Verification note from the field:
ps -o command=shows 0 matches — that's truncation;ps -p <pid> -ww -o command=shows the variable in argv on every shellper sampled.Severity: hygiene, not incident (deliberately calibrated down by the reporting owner)
Not an access-control hole on a single-user dev machine: same-user processes can read the env regardless, and the other-account processes on typical macOS hosts are service daemons. The real, demonstrated risk is accidental disclosure: argv is what gets pasted into bug reports, logs, and agent transcripts — in the reporting workspace, a routine
psduring a hung-process diagnosis pulled the secret into an agent's conversation context.psoutput travels; env mostly doesn't. Weight increases in any CI or shared-host context running the same path.Fix shape (cheap, contained)
Stop putting
env(and ideally the whole config) in argv: pass it via the child's process environment, a pipe/stdin, or an inherited fd — the shellper already has a socket handshake (HELLO/WELCOME) that could carry config equally well. Nothing else changes; argv exposure disappears. Note the RECONNECT path already sends spawn config over the socket (msg.envatshellper-process.ts:495), so the socket-borne shape has precedent in the same file.Related-not-duplicate: #1219/#1626/#1627 (inherited-env contamination — different defect, same hygiene family).