This is a fully-automated contribution trying to expand on the success of #30432.

Fixes #30882.

Summary

This closes the remaining execute_code bypass in gateway manual approval mode. Current main already has a blocking gateway approval queue for terminal commands, but execute_code can spawn a local Python child before any terminal guard sees the subprocess/os calls inside that script.

Root Cause

execute_code scripts run arbitrary Python. A script can call subprocess.run(...), os.system(...), ctypes, or other process/file APIs directly, so dangerous shell behavior can happen without going through terminal() and without matching DANGEROUS_PATTERNS as a shell command.

What Changed

• Added check_execute_code_guard() in tools/approval.py.
• Before local/SSH execute_code spawns the child process, gateway/ask contexts now submit a one-shot approval request through the existing blocking gateway approval queue.
• User denial, timeout, missing notify callback, or guard failure all fail closed before the script runs.
• approvals.mode: off and session/process YOLO still bypass this guard intentionally.
• Container/cloud backends keep the existing approval behavior, matching terminal command approval's existing skip for isolated backends.
• Cron sessions with approvals.cron_mode: deny now block local/SSH execute_code, because no user is present to approve arbitrary script execution.
• Shared the gateway approval wait helper with the existing terminal approval path so approval waits continue feeding the inactivity watchdog.

Regression Coverage

Added tests/tools/test_code_execution.py coverage for:

• gateway denial blocks execute_code before the child process is spawned, verified with a marker file that never appears;
• one-shot gateway approval allows the script to continue and return normal output.

Validation

• .venv/bin/python -m ruff check tools/approval.py tools/code_execution_tool.py tests/tools/test_code_execution.py
• .venv/bin/python -m py_compile tools/approval.py tools/code_execution_tool.py tests/tools/test_code_execution.py
• HOME=/tmp/hermes-test-home scripts/run_tests.sh tests/gateway/test_approve_deny_commands.py
• HOME=/tmp/hermes-test-home scripts/run_tests.sh tests/tools/test_cron_approval_mode.py
• HOME=/tmp/hermes-test-home .venv/bin/python -m pytest tests/tools/test_code_execution.py::TestExecuteCodeEdgeCases::test_gateway_execute_code_denial_blocks_child_process -q
• HOME=/tmp/hermes-test-home .venv/bin/python -m pytest tests/tools/test_code_execution.py::TestExecuteCodeEdgeCases::test_gateway_execute_code_runs_after_one_shot_approval -q
• HOME=/tmp/hermes-test-home scripts/run_tests.sh tests/tools/test_code_execution.py passed outside the local filesystem sandbox; inside the sandbox this file hit the existing UDS bind restriction (PermissionError: [Errno 1] Operation not permitted) across pre-existing execute_code tests.

Assumptions

• The intended security contract for gateway manual approvals is fail-closed for local/SSH arbitrary code execution, because the generated script can bypass command-string inspection.
• Docker, Singularity, Modal, Daytona, and Vercel Sandbox should retain the existing container/cloud approval behavior used by terminal commands.
• A one-shot approval is the right scope for execute_code; /approve session or /approve always resolves the current wait but this guard does not persist a broad allowlist for future scripts.