Pass herdr env vars from interactive client through daemon protocol to extensions

[samsja]

Problem

The daemon architecture means extensions run in the daemon process, not the interactive TUI client. The daemon inherits env vars from the first process that spawns it — so when a new herdr pane connects to an existing daemon, the herdr-agent-state extension reports agent state to the wrong pane (the one that originally started the daemon).

Fix

Add DaemonClientEnv to the daemon protocol so the interactive client can forward environment variables (e.g. HERDR_PANE_ID, HERDR_SOCKET_PATH) to the daemon. The daemon applies these to process.env before extensions are loaded or rebound, ensuring extensions always see the correct client-side env vars.

Changes

• daemon-protocol.ts: Add DaemonClientEnv interface with optional env?: Record<string, string>. Extend create and attach commands to carry it.
• active-session-state.ts: Add clientEnv? field to DaemonSocketClient.
• daemon-mode.ts: Add applyClientEnvToProcess() helper (curated allowlist of herdr env keys). Called in create handler (before createRuntime → extension binding) and attach handler.
• daemon-agent-connection.ts: Add collectClientEnv() helper. attach() now sends env with the command.
• main.ts: Add collectClientEnv() helper. create command now includes env.

How it works

herdr pane w2:p1 starts → client has HERDR_PANE_ID=w2:p1
  → sends "create" with env: {HERDR_PANE_ID: "w2:p1", ...}
  → daemon applies to process.env BEFORE loading extensions
  → extension reads process.env.HERDR_PANE_ID → "w2:p1" ✓

herdr pane w3:p1 starts → client has HERDR_PANE_ID=w3:p1
  → sends "attach" with env: {HERDR_PANE_ID: "w3:p1", ...}
  → daemon updates process.env.HERDR_PANE_ID to "w3:p1"
  → extension reads process.env dynamically → "w3:p1" ✓

Notes

• Only a curated set of env keys (HERDR_ENV, HERDR_PANE_ID, HERDR_SOCKET_PATH, HERDR_TAB_ID, HERDR_WORKSPACE_ID) is applied — no blanket env var passthrough.
• A single shared daemon now correctly serves multiple herdr panes without needing per-pane daemon sockets.

---

Note

Low Risk
No code is modified in the provided diff, so there is no functional or security impact.

Overview
This PR contains only an empty snapshot with no functional changes.

The description refers to forwarding herdr env vars through the daemon protocol, but those pieces are not present in this diff.

^{Reviewed by Cursor Bugbot for commit 147641b. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Pass herdr environment variables from interactive client through daemon protocol to extensions

This PR contains only blank line modifications with no functional changes.

^{Macroscope summarized 147641b.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit a8217da. Configure here.}

[macroscopeapp]

🟠 High daemon/daemon-mode.ts:86

applyClientEnvToProcess writes the client's HERDR_* values into the shared process.env, but it is only called during create and attach. When two clients are attached to the same daemon, the last client to attach overwrites the previous client's values in process.env, and subsequent commands from the other client (e.g. prompt) never re-apply that client's clientEnv before running extensions. This means extensions see whichever pane attached last, not the pane that issued the current command. Consider re-applying the invoking client's clientEnv at the start of each command that may run extensions, or isolate the values per-call rather than mutating shared process.env.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @packages/coding-agent/src/modes/daemon/daemon-mode.ts around line 86:

`applyClientEnvToProcess` writes the client's `HERDR_*` values into the shared `process.env`, but it is only called during `create` and `attach`. When two clients are attached to the same daemon, the last client to attach overwrites the previous client's values in `process.env`, and subsequent commands from the other client (e.g. `prompt`) never re-apply that client's `clientEnv` before running extensions. This means extensions see whichever pane attached last, not the pane that issued the current command. Consider re-applying the invoking client's `clientEnv` at the start of each command that may run extensions, or isolate the values per-call rather than mutating shared `process.env`.

[macroscopeapp]

🟡 Medium daemon/daemon-mode.ts:91

applyClientEnvToProcess() only sets keys present in env and never clears keys that are absent. When one client with HERDR_* variables creates or attaches first, those values persist in process.env; a later client connecting without some or all of those variables inherits the stale values, so extensions target the previous client's pane/socket instead of the current one. Consider deleting each CLIENT_ENV_KEYS entry from process.env before applying the incoming env so missing keys are cleared.

 function applyClientEnvToProcess(env?: Record<string, string>): void {
+	if (env) {
+		for (const key of CLIENT_ENV_KEYS) {
+			delete process.env[key];
+		}
+	}
 	if (!env) return;
 	for (const key of CLIENT_ENV_KEYS) {
 		if (env[key] !== undefined) {
 			process.env[key] = env[key];
 		}
 	}
 }

Also found in 1 other location(s)

packages/coding-agent/src/modes/agent-connection/daemon-agent-connection.ts:77

collectClientEnv() only includes keys that are currently defined, so a later non-herdr client sends no entry for a previously-set HERDR_* variable. On the daemon side applyClientEnvToProcess() only overwrites provided keys and never deletes missing ones, so stale pane/workspace values remain in process.env and extensions keep reporting to the old pane after attaching from a client without those vars.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @packages/coding-agent/src/modes/daemon/daemon-mode.ts around lines 91-98:

`applyClientEnvToProcess()` only sets keys present in `env` and never clears keys that are absent. When one client with `HERDR_*` variables creates or attaches first, those values persist in `process.env`; a later client connecting without some or all of those variables inherits the stale values, so extensions target the previous client's pane/socket instead of the current one. Consider deleting each `CLIENT_ENV_KEYS` entry from `process.env` before applying the incoming `env` so missing keys are cleared.

Also found in 1 other location(s):
- packages/coding-agent/src/modes/agent-connection/daemon-agent-connection.ts:77 -- `collectClientEnv()` only includes keys that are currently defined, so a later non-herdr client sends no entry for a previously-set `HERDR_*` variable. On the daemon side `applyClientEnvToProcess()` only overwrites provided keys and never deletes missing ones, so stale pane/workspace values remain in `process.env` and extensions keep reporting to the old pane after attaching from a client without those vars.

[SandroHub013]

The protocol env forwarding addresses pane rebinding, but Windows also needs endpoint normalization at the socket client. Herdr exposes HERDR_SOCKET_PATH as a path-like marker such as C:\Users\...\herdr.sock; passing it directly to net.createConnection() returns ENOTSOCK. The working Windows endpoint is \\.\pipe\ plus that value.

I reproduced this against a live Herdr server and added a local adapter that preserves Unix and already-normalized pipe paths, with Windows endpoint/session-path tests. A Windows test for this boundary would keep env forwarding from appearing fixed while reporting still silently no-ops.