Why: plan §3.4 observed the dev service carrying the credential-bearing DSN as serve --dsn, visible to any host process (ps/cmdline) including agent-generated scripts. The base config already supports AGENT_SYSTEM_DSN, so the launcher moves the secret out of argv.
Evidence: bash -n clean; make test-governance 104/104 green; stub-binary probe with legacy exec= shows MIGRATED:yes, NO-LEAK-IN-CMDLINE, DSN_IN_ENV:yes. New launches never put DSN in argv; legacy configs migrate on first reuse.
Refs: plan G1-7 (line 356), §3.4; AGENT_SYSTEM_DSN.
Why: plan §3.4 observed the dev service carrying the credential-bearing DSN as serve --dsn, visible to any host process (ps/cmdline) including agent-generated scripts. The base config already supports AGENT_SYSTEM_DSN, so the launcher moves the secret out of argv.
Evidence: bash -n clean; make test-governance 104/104 green; stub-binary probe with legacy exec= shows MIGRATED:yes, NO-LEAK-IN-CMDLINE, DSN_IN_ENV:yes. New launches never put DSN in argv; legacy configs migrate on first reuse.
Impact: scripts/svc.sh only; CLI --dsn precedence unchanged.
Refs: plan G1-7 (line 356), §3.4; AGENT_SYSTEM_DSN.
Why: the plan section 3.4 observed the local dev service carrying the
credential-bearing DSN as a serve --dsn argument, visible to any
process on the host (ps / /proc/<pid>/cmdline) — including scripts
generated by agents. The base config layer already supports
AGENT_SYSTEM_DSN, so the launcher can move the secret out of the
argument vector without touching the binary.
Evidence: bash -n clean; make test-governance 104/104 green; an
end-to-end probe with a stub binary and a legacy exec= carrying
--dsn ...secret... shows the migration stripping the flag
(MIGRATED:yes), the process args free of the secret
(NO-LEAK-IN-CMDLINE), and AGENT_SYSTEM_DSN present in the process
environment (DSN_IN_ENV:yes). New/rebuilt launches never put the DSN
in argv; legacy persisted configs are migrated on first reuse.
Impact: scripts/svc.sh only — rebuild path sets DSN_ENV instead of
--dsn, reuse path strips --dsn from stored exec= once and logs the
migration, launch injects AGENT_SYSTEM_DSN alongside the existing
guard vars. CLI --dsn still wins inside the binary (config
precedence), so manual invocations are unchanged.
Refs: plan G1-7 (line 356) and section 3.4 (2026-10-09 ps
observation); backend config AGENT_SYSTEM_DSN.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Why: plan §3.4 observed the dev service carrying the credential-bearing DSN as serve --dsn, visible to any host process (ps/cmdline) including agent-generated scripts. The base config already supports AGENT_SYSTEM_DSN, so the launcher moves the secret out of argv.
Evidence: bash -n clean; make test-governance 104/104 green; stub-binary probe with legacy exec= shows MIGRATED:yes, NO-LEAK-IN-CMDLINE, DSN_IN_ENV:yes. New launches never put DSN in argv; legacy configs migrate on first reuse.
Impact: scripts/svc.sh only; CLI --dsn precedence unchanged.
Refs: plan G1-7 (line 356), §3.4; AGENT_SYSTEM_DSN.
74ae7520aftoa6d434e432