Headless session env: are DSH_-prefixed variables intentionally dropped before reaching the session?

[guytogay]

Hi — reporting two runtime observations from a real deployment (Linux container, DSH 0.1.1-rc.2, --profile headless), in case they are useful. Both are reproducible; I did not isolate the exact mechanism, so I am reporting behavior rather than claiming a bug.

1. DSH_-prefixed environment variables do not reach the spawned headless session.
We passed an attribution marker on the parent process environment when spawning dsh --profile headless <task>.
Inside the session, the tool that reads it saw nothing (recorded UNKNOWN). Renaming the variables to a non-DSH prefix made them visible immediately; same host, same profile, same invocation. We could not determine whether the filter is applied to the DSH process environment or only to the session it spawns, so this is a phenomenon report: if you need to pass provenance into a dispatched session, a non-DSH_ prefix works; DSH_-prefixed names appear to be dropped. If that is intended namespacing hygiene, it may be worth one line in the docs.

2. MCP client tool registration is not refreshed after a connection failure.
A streamable-HTTP MCP server was unreachable when the session started (every call returned fetch failed). After the server came back, calls in the same session returned unknown tool — the tool list was never re-fetched — and only a new session could use the server. If accurate, re-listing tools on reconnect/retry would make long-lived sessions recover without a restart.

3. Session logs can end with a partial zstd frame.
session.jsonl.zstd may end mid-frame while live. A tail decoder that walks frame boundaries can distinguish "torn at the tail (expected while writing)" from "torn in the middle (corruption)". Not a request — just noting the distinction we had to make.

Happy to provide minimal reproductions (sanitized: no private addresses or paths). Thanks for the harness.

[PerryLink]

Thanks — all three observations are useful; #1 and #2 have clear answers in the source.

1. DSH_-prefixed env: yes, dropped intentionally — it is namespace hygiene. Two independent layers:

• The subprocess seam's scrubbedParentEnv() (packages/subprocess/subprocess/src/index.ts:64-78)
  builds the canonical environment for every spawned child: credential-shaped names
  (/KEY|PASSWORD|SECRET|TOKEN/i, line 45) and every DSH_* name (case-insensitive) are dropped.
  The headless session's tool/MCP children inherit from this scrub — e.g. the MCP transport's
  buildChildEnv() is { ...scrubbedParentEnv(), ...extra }
  (packages/mcp/mcp-client/src/transport.ts:21-23), and the SDK subagent spawn merges spec.env
  the same way (packages/subagent/subagent-dsh-sdk/src/run.ts:245). DSH_* is the harness's own
  namespace (bootstrap switches, identity) and is never forwarded to children implicitly.
• Separately, .env files may not set DSH_/XDG_/DYLD_/BASH_FUNC_ at all: BOOTSTRAP_PREFIXES
  (packages/boot/app-boot/src/index.ts:117) makes readEnvLayer() throw at startup
  ("... sets "X", which only the launching environment may set ...; export X instead of
  putting it in a .env file", lines 167-180). That layer refuses loudly rather than dropping.

To pass provenance explicitly, either route works:

• put the value in the child's configured env — the MCP server config's env, or the tool/subagent
  spec's env — explicit entries merge after the scrub and survive (your dsh process still sees the
  ambient variable, so a config that forwards it deliberately works);
• or use a non-DSH_ prefix, which you already confirmed works.

Agreed that a user-facing doc line is warranted; the semantics live in the package READMEs
(subprocess, mcp-client, app-boot) but a single sentence would help.

2. MCP tool list after reconnect: current master has an automatic reconnect policy with tool
   re-sync — mcp-client resolves a reconnect policy (packages/mcp/mcp-client/src/index.ts:71-72)
   and the connection supervisor retries and re-lists tools ("reconnected and re-synced tools",
   src/connection.ts:304; after maxAttempts it gives up with tools unregistered and logs
   "reload the plugin or restart the Host", line 213). I can't verify from the checkout whether your
   0.1.1-rc.2 build already contained that supervisor; please retest on a current rc — if a
   mid-session recovery still leaves stale tools, file a focused report with the server config and
   supervisor logs and we'll dig in.

3. zstd torn-tail distinction noted — no action requested.

Unverified: verified statically against master (c291e79); I did not re-run your exact
0.1.1-rc.2 deployment.