[Guan0923]

What and why

Keep code_execution and js_execution, but route their interpreter processes through the existing permission-aware launcher.

Previously, interpreter dispatch passed only the tool input and workspace path to the Python and Node runners. After approval, both runners launched local interpreters directly without applying the effective session sandbox policy.

A working directory is not filesystem confinement. Environment sanitization, timeouts, and process-tree cleanup are useful protections, but they do not enforce filesystem or network restrictions.

This change connects both tools to the existing execution-policy mechanism. It does not introduce another sandbox implementation or require ordinary interpreter calls to be rewritten as Shell calls.

Explicitly authorized wider execution remains supported: ordinary approval retains the current policy, while a separately approved elevation applies only to the corresponding call.

Changes

• Pass the effective ToolContext, including per-call policy overrides, to both interpreter runners.
• Refuse interpreter dispatch without an effective context instead of falling back to an unconstrained local launch.
• Build Python and Node commands through the existing sandboxed_runner_command.
• Add optional sandbox_permissions and justification fields to both tool schemas.
• Extend the existing sandbox-elevation validation and approval flow to these interpreter tools:
  • require a valid permission/justification pair;
  • require a strictly wider policy;
  • require explicit one-shot user approval in Ask mode;
  • refuse elevation when the current posture cannot provide that approval.
• Deliver source through stdin rather than a host temporary script, avoiding script visibility problems with sandbox-private /tmp.
• Preserve the result payload, existing execution budgets, environment sanitization, and process-tree cleanup.
• Preserve Node proxy handling without clearing the environment prepared by the shared launcher.
• Replace approval wording that implied guaranteed sandbox isolation.
• Update tool documentation, the feature registry, and existing runner callers/tests.

Authorization behavior

The two decisions remain distinct:

Decision	Execution behavior
Ordinary approval	Run with the effective session policy; approval does not implicitly grant full access.
Explicit approval of a wider policy	Run this exact call with the approved policy; do not change the session default.
Elevation request without an available human approval path	Refuse the request.
Local interpreter call in an external-sandbox session	Refuse local execution rather than silently bypassing the configured backend.

The tools retain their names and their required code input. Callers that need a wider policy can request it through the same interpreter tool instead of switching to Shell solely to obtain approval.

Scope and known limitations

• This is a policy-plumbing fix, not a new operating-system sandbox.
• Native enforcement still depends on the platform and configured backend.
• The shared launcher currently refuses read-only execution when native enforcement is unavailable.
• Without an available local wrapper, workspace-write retains the existing unenforced behavior. This change does not add Windows filesystem or network isolation.
• External-backend sessions cannot use these local interpreter runners; they must use the backend-supported execution path.
• Source is now delivered through stdin. Tracebacks refer to stdin rather than a generated temporary script filename. Node execution explicitly uses CommonJS.
• Python keeps its 120-second production budget; JavaScript keeps its 600-second production budget.
• The separate RLM/REPL kernel is unchanged. Existing Plan/REPL admission checks remain in place.
• Neither dedicated tool is removed, and no additional execution framework is introduced.

How I tested it

Local verification was performed on Windows.

Focused TUI tests

Group	Result
Python execution and existing Plan/REPL checks	7 passed; 0 failed
Interpreter execution-policy regressions	2 passed; 0 failed
JavaScript execution, errors, credentials, proxy handling, and schema	8 passed; 0 failed
Sandbox-elevation validation and approval journeys	4 passed; 0 failed

These are 21 distinct passing TUI tests, not a full-suite run.

Cargo invocations included:

cargo test --offline --locked -p codewhale-tui --lib -j 1 code_execution -- --test-threads=1
cargo test --offline --locked -p codewhale-tui --lib -j 1 interpreter_execution_policy -- --test-threads=1

The js_execution and sandbox_escalation groups were run directly from the compiled TUI unit-test binary.

The runtime regressions cover both interpreter entrypoints:

• restrictive calls cannot perform the attempted writes;
• explicitly wider per-call policies allow execution;
• subsequent read-only calls remain restricted;
• an external execution boundary cannot silently become a local interpreter launch.

The existing engine approval journeys were extended to cover Python and JavaScript, including approval before execution and refusal in postures that cannot provide the required human decision.

Negative control

Temporarily bypassed the shared launcher and restored direct local command construction while keeping the same source-delivery path.

Both permission regressions failed:

test result: FAILED. 0 passed; 2 failed

After restoring the fixed sources and rebuilding, both passed again:

test result: ok. 2 passed; 0 failed

Feature registry and formatting

• Independently compiled and executed the original feature-registry test source with cached dependencies: 6 passed; 0 failed.
• This was a standalone test-source run, not a full Cargo integration-test build.
• cargo fmt --all -- --check passed.
• git diff --check passed.

Not run locally:

• the full workspace suite;
• live Linux Bubblewrap or macOS Seatbelt confinement;
• packaged/released application acceptance.

Issue

No-Issue: This PR replaces its original design-only proposal with the implemented interpreter-policy repair; no separate issue is linked.

The original proposal commits remain in the branch history. The RFC-only document is no longer part of the final diff, which contains the verified repair instead of an unimplemented direction discussion.

Checklist

• Started from fetched origin/main before implementation.
• Reused the existing execution-policy and elevation mechanisms.
• Updated documentation and the feature registry.
• Ran focused execution and authorization tests.
• Demonstrated that the permission regressions fail when enforcement is bypassed.
• Documented platform limitations and stdin-related behavior changes.
• Preserved published branch ancestry; no force push.
• No release, deployment, or cross-platform acceptance claim.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.