[krimvp]

Fixes #2866

What changed

timeout_seconds on Bash and BashTool now also sets the embedded runtimes' own per-run time limit (max_duration for Monty python3 and ZapCode ts), the same way Bash already passes it to SQLite. It applies to construction, reset(), snapshot factories, and the external-handler paths.

Each run is still clamped to the remaining execution deadline, and a per-call execute(timeout_seconds=...) can still only shorten it. Callers who don't set timeout_seconds see no change.

Why

The runtimes take their time limit from the execution profile (30 s, or 10 s under Hardened), and timeout_seconds only raised the shell timeout. So Bash(python=True, timeout_seconds=120) still stopped python3 at 30 s, and Python callers had no way to raise it, because ExecutionProfile is a closed set.

Before / After

Bash(python=True, timeout_seconds=40).execute_sync("python3 -c 'while True: pass'"):

	Elapsed	Result
Before (PyPI 0.20.3, timeout_seconds=120)	30.0 s	TimeoutError: time limit exceeded: 30.000000166s > 30s
After	40.0 s	exit 124, python3: execution timed out after 40.0s

New test test_timeout_seconds_raises_runtime_time_limit (Hardened profile, timeout_seconds=11):

• Before: python3 and ts stop at 10.0 s, and the test fails.
• After: both run to about 11 s, and the test passes.

The full Python suite passes locally: 966 passed, 7 skipped.

Risk

• Low.
• A long ts run is still bounded by the execution work budget (one unit per µs of VM time, so about 100 s Standard and 25 s Hardened). This PR documents that in knowledge/ and doesn't change it.
• The JS binding has the same gap: timeoutMs only reaches SQLite. It's left for a follow-up to keep this PR small.
• The new test costs about 22 s per Python CI job, because Hardened's 10 s limit is the lowest one reachable from Python.

Checklist

• Tests added or updated
• Backward compatibility considered

---

^{Open in [code]smith · Need help on this PR? Tag @codesmith-bot with what you need.}

[bashkit-pr-reviewer]

Review summary — #2864 timeout_seconds raises embedded runtime limit (update for 9b404a1)

Verdict: Still sound, no blocking issues. New head 9b404a1 adds only the mirrored timeout_seconds wording to site/src/content/apidocs/python.md (Bash + BashTool constructors); the lib.rs / .pyi / test / knowledge hunks are unchanged from d2b3cd9. Full diff visible (truncated: false).

Re-verified since last review:

• Site docs change matches the already-reviewed .pyi wording (embedded python3/ts per-run limit, default 30 s / Hardened 10 s). No code or test change in this push, so prior findings stand (none open).
• PR description's "per-call execute(timeout_seconds=...) can still only shorten it" holds: construction bakes max_duration into the interpreter's runtime limits, while per-call timeout flows into ExecOptions::timeout → execution deadline; the builtin then runs with min(max_duration, deadline remaining) plus the unchanged max_work_units budget, so a larger per-call value cannot lift the construction-time runtime cap.

Findings: None (no P0/P1/P2). Earlier note still applies as non-blocking: the new timing test asserts exit_code != 0 + elapsed time, not the timeout stderr.

Context read: previous review's sources plus site/src/content/apidocs/python.md timeout_seconds hunks and the ExecOptions/builtin deadline-clamp paths.

Not reviewed: Nothing — no build/test run per project rules (code reasoning only).

[chaliy]

Thanks @krimvp! Your two commits landed unchanged (rebased onto main) in #2873, squash-merged as d4e50b5 with you as co-author. On top we added an upper bound and exit-124 check to the test, and a threat-model entry (TM-PY-039) noting that a longer per-run cap lets a CPU-bound run hold a shared worker thread longer. Closing this one as superseded.

---

Generated by Claude Code