fix(code-execution): the python runner gets the child allowlist too (follow-up to #175)

[slimepriestess]

#175 scrubbed the host environment from stdio MCPL children — one of the two child-spawn paths in the framework. The other one, the python interpreter behind code_execution (src/code-execution/py-runner.ts), still spawned with { ...process.env }. That child runs model-authored code, so on any host with code execution enabled, one os.environ read handed the model every provider key and bot token on the box. Verified red before the fix: a model-authored script printed a planted host secret. This was flagged in the #175 review and offered as a stacked lift (9e8ec77); #175 merged without it, so here it is rebased onto main as its own PR.

What it does

• PyRunner builds its child env through the same buildChildEnv as fix(mcpl): scrub host env from stdio MCPL children #175: operating allowlist (+ LC_*), plus the runner's own env, with inheritEnv: true as the same explicit escape hatch. PYTHONUNBUFFERED stays.
• CodeExecutionConfig carries env / inheritEnv and the framework threads them to both runner construction sites.
• With this in, the fix(mcpl): scrub host env from stdio MCPL children #175 changelog claim ("one server's credentials are no longer readable by another") is also true on hosts running code execution.

Receipts (head 4ed84f7, on main 5498805)

• Full suite: 973 tests, 969 pass, 0 fail, 4 skipped; tsc clean.
• Revert-goes-red: reverting py-runner.ts alone turns test/code-execution-env.test.ts red (0 pass / 2 fail) — the new test reads a planted secret from inside the child and asserts it isn't there.

(Weft — reviewed and submitted via Ra's account, per the usual convention.)

🤖 Generated with Claude Code

[greptile-apps]

Confidence Score: 3/5

[Critical risk] Restricts environment variables passed to model-authored code execution.

The PR should not merge until Windows search-path handling and environment refresh on interpreter respawn are addressed.

Findings

1.  Windows search path is dropped ▶
2.  Respawns retain stale environment ▶

Fix with agent prompt

### Issue 1
src/code-execution/py-runner.ts:124
If the host's search-path variable is named `Path`, the case-sensitive allowlist does not include it in the Python child's environment. Even when `pythonPath` is absolute, model-authored scripts can no longer launch programs found only through that host search path.

### Issue 2
src/code-execution/py-runner.ts:124
With `inheritEnv: true`, this captures the host environment when the runner is created. If the host updates a credential and the cached runner later respawns after idle reclaim, the new interpreter still receives the old value, so scripts using the updated credential can fail authentication. The previous spawn path read `process.env` for each spawn.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

The PR applies the MCPL child-environment allowlist to model-authored Python execution, adds configuration for declared environment variables and full inheritance, and tests the direct runner behavior.

• Windows path-variable casing can leave the interpreter without the host search path.
• Constructor-time environment capture makes later interpreter spawns use stale host values.
• The tests do not cover the new framework configuration wiring.

_{Reviews (1) · Last reviewed commit: "fix(code-execution): the python interpre..."}

[greptile-apps]

Windows search path is dropped If the host's search-path variable is named Path, the case-sensitive allowlist does not include it in the Python child's environment. Even when pythonPath is absolute, model-authored scripts can no longer launch programs found only through that host search path.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/code-execution/py-runner.ts
Line: 124

Comment:
**Windows search path is dropped** If the host's search-path variable is named `Path`, the case-sensitive allowlist does not include it in the Python child's environment. Even when `pythonPath` is absolute, model-authored scripts can no longer launch programs found only through that host search path.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Respawns retain stale environment With inheritEnv: true, this captures the host environment when the runner is created. If the host updates a credential and the cached runner later respawns after idle reclaim, the new interpreter still receives the old value, so scripts using the updated credential can fail authentication. The previous spawn path read process.env for each spawn.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/code-execution/py-runner.ts
Line: 124

Comment:
**Respawns retain stale environment** With `inheritEnv: true`, this captures the host environment when the runner is created. If the host updates a credential and the cached runner later respawns after idle reclaim, the new interpreter still receives the old value, so scripts using the updated credential can fail authentication. The previous spawn path read `process.env` for each spawn.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[slimepriestess]

Both Greptile findings were real; fixed in the second commit. The env is now rebuilt at every spawn (a respawn after idle reclaim sees current host values, matching the old per-spawn behavior), and buildChildEnv matches the allowlist case-insensitively on win32 while keeping the host's original spelling — POSIX stays exact-case, since Path genuinely is a different variable there. That second fix also closes the Windows-casing note from the #175 review. Receipts: each test red on the prior head, full suite 976/972/0.