[chaliy]

Requested by Михайло · project thread

Supersedes #2864 by @krimvp (their two commits kept as-is, rebased onto main), plus one follow-up commit from review. Fixes #2866.

What changed

timeout_seconds on Python Bash and BashTool now also sets the embedded runtimes' per-run time limit (max_duration for python3 and ts), the same way Bash already passes it to SQLite. Each run stays clamped to the remaining execution deadline; per-call execute(timeout_seconds=...) can still only shorten it. No change for callers who don't set it.

Review follow-up:

• Test now asserts exit 124, the timed out message, and an upper bound (10.5 < elapsed < 20), so a run that ignores the deadline fails.
• New threat-model entry TM-PY-039: a CPU-bound python3/ts loop yields its worker thread only at host calls, so raising timeout_seconds raises the longest time one tenant can hold a shared worker thread (previously capped at the profile's 30 s / Hardened 10 s). Noted in the timeout_seconds docstring, API reference and python-package knowledge.

Why

Bash(python=True, timeout_seconds=120) still stopped python3 at 30 s, and Python callers had no other way to raise it (ExecutionProfile is a closed set).

Before / After

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

	Elapsed	Result
Before	30.0 s	TimeoutError: time limit exceeded: 30.000000166s > 30s
After	40.0 s	exit 124, python3: execution timed out after 40.0s

test_timeout_seconds_raises_runtime_time_limit (Hardened, timeout_seconds=11) passes for both python3 and ts. Local: pytest crates/bashkit-python/tests 938 passed, 16 skipped (test_filesystem_interop.py skipped locally, needs a CI-built fixture module). ruff, cargo fmt, OKF check clean.

Risk

• Low.
• Hosts that set a large timeout_seconds now let one python3/ts run hold a worker thread that long (TM-PY-039).
• ts runs still stop at the work budget (~100 s Standard, ~25 s Hardened). The JS binding's timeoutMs has the same gap, left for a follow-up.
• Test adds ~22 s per Python CI job.

Checklist

• Tests added or updated
• Backward compatibility considered

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	bashkit	6a54a99	Commit Preview URL Branch Preview URL	Nov 07 2026, 03:51 AM

[bashkit-pr-reviewer]

Review verdict: sound, no blocking issues (re-reviewed at 6a54a99)

This push is a pure rebase onto new main (base a318206b → 371fb279): same 8 files, same +104/−26 stats, and I re-verified the substance is byte-identical to what I reviewed at 1453079 — the python_limits/typescript_limits helpers in crates/bashkit-python/src/lib.rs, the Hardened 11 s test for both Bash+python3 and BashTool+ts, the TM-PY-039 rows in both crates/bashkit/docs/threat-model.md and knowledge/security/threat-model.md, plus the .pyi/knowledge/site doc updates. The load-bearing invariant the fix relies on is still in place after the rebase: crates/bashkit/src/builtins/python.rs:407 clamps each run with max_duration.min(remaining) against the live execution deadline, so construction timeout_seconds can raise the per-run cap but no run outlives its deadline, and per-call execute(timeout_seconds=...) can only tighten.

Findings: none. The earlier P2 (Node binding timeoutMs gap) remains acknowledged in the PR Risk section as a follow-up — not re-raised.

What I could not do: no cargo/test execution in this shell — validation by code reading only (author reports pytest crates/bashkit-python/tests 938 passed, ruff/cargo fmt/OKF clean). Full diff visible (truncated: false); nothing unreviewed.