[Bug]: The environment variables ORCA_ROOT_PATH and ORCA_WORKTREE_PATH do not exist.

[aliuq]

Operating system

Windows

Orca version

1.4.144

Details

• WSL

---

Setup script

cp "$ORCA_ROOT_PATH/.env" "$ORCA_WORKTREE_PATH/.env"
bun install

Logs

bash /home/xxx/xxx/.git/worktrees/dev/orca/setup-runner.sh
cp: cannot stat '/.env': No such file or directory

File

cat /home/xxx/xxx/.git/worktrees/dev/orca/setup-runner.sh                                                                         
#!/usr/bin/env bash
set -e
cp "$ORCA_ROOT_PATH/.env" "$ORCA_WORKTREE_PATH/.env"
bun install

[nwparker]

Status: REPRODUCED (unit test pinning the buggy behavior)

Root cause: On WSL the setup-runner.sh runs inside wsl.exe, which only imports env vars whose names are listed in WSLENV. The setup vars are generated and Linux-path-translated correctly (src/main/hooks.ts:343/458/555-559), but the only WSLENV gatekeeper on the WSL spawn path — addOrcaWslInteropEnv (src/main/pty/wsl-orca-env.ts:17, called at src/main/daemon/pty-subprocess.ts:759 and mirrored in local-pty-provider.ts) — has a fixed passthrough allowlist (wsl-orca-env.ts:24-41) that omits ORCA_ROOT_PATH, ORCA_WORKTREE_PATH, ORCA_WORKSPACE_NAME, CONDUCTOR_ROOT_PATH, and GHOSTX_ROOT_PATH. So the values are set on the Windows side but never cross into WSL bash, and cp "$ORCA_ROOT_PATH/.env" "$ORCA_WORKTREE_PATH/.env" expands to cp /.env /.env.

Fix direction: add the setup var names to the passthroughEntries allowlist in addOrcaWslInteropEnv (values are already Linux-translated, so use the u flag).

Re-run:

pnpm exec vitest run --config config/vitest.config.ts src/main/repro-9206-wsl-setup-env-not-crossing.test.ts

Key files: src/main/pty/wsl-orca-env.ts, src/main/hooks.ts, src/main/daemon/pty-subprocess.ts, src/main/providers/local-pty-provider.ts.

---

Automated bug-reproduction pass. Repro artifact committed on branch nwparker/bug-repro-pass2; check it out to run the command above. Writeup: docs/bug-reproductions/9206.md.

[OrcaWin]

Confirmed at the source level (verdict: reproduced). The repro box couldn't run a live WSL distro, so this is a code trace plus a unit test proving the propagation gap.

Root cause: the setup env vars never cross the wsl.exe boundary.

Orca sets ORCA_ROOT_PATH / ORCA_WORKTREE_PATH correctly and even Linux-path-translates them, then hands them to the setup terminal:

1. getSetupEnvVars defines them — src/main/hooks.ts:343-352.
2. createWorktreeRunnerScript writes setup-runner.sh and Linux-path-translates the values for WSL — src/main/hooks.ts:552-559.
3. The setup pane spawns with env: setup.envVars — src/renderer/src/lib/launch-worktree-background-terminals.ts:214 and src/renderer/src/lib/worktree-activation.ts:743.
4. For a WSL worktree the PTY shell is wsl.exe, and Orca builds WSLENV from a fixed allowlist in addOrcaWslInteropEnv (src/main/pty/wsl-orca-env.ts:24-41). That allowlist does not include ORCA_ROOT_PATH, ORCA_WORKTREE_PATH, ORCA_WORKSPACE_NAME, CONDUCTOR_ROOT_PATH, or GHOSTX_ROOT_PATH.

wsl.exe only imports Windows env vars registered in WSLENV; everything else is dropped. So the vars are present on the Windows-side spawn env but never reach bash inside the distro — $ORCA_ROOT_PATH expands to empty, and cp "$ORCA_ROOT_PATH/.env" … becomes cp "/.env" …, exactly matching the report.

This is WSL-specific: native Windows runs a .cmd in-process via cmd.exe (no boundary), so the vars are visible there.

Repro test (passes today, documenting the gap; flip its expectation once fixed):

npx vitest run --config config/vitest.config.ts src/main/pty/wsl-orca-env.test.ts

"DOES NOT forward the setup env vars across the wsl.exe boundary (#9206)"

Fix direction: add ORCA_ROOT_PATH, ORCA_WORKTREE_PATH, ORCA_WORKSPACE_NAME, CONDUCTOR_ROOT_PATH, GHOSTX_ROOT_PATH to the passthroughEntries allowlist in src/main/pty/wsl-orca-env.ts so they get registered in WSLENV (values are already Linux-translated, so a /u flag fits).

Full trace in docs/bug-reproductions/9206-wsl-setup-env-vars-empty.md.

_{🔁 Reproduced via automated Windows bug-reproduction pass.}

[OrcaWin]

will be in next release, usually within 24 hours