Hidden 270s absolute timeout overrides caller's timeout arg in run_shell_command; error message reports wrong limit

File: code_puppy/tools/command_runner.py - run_shell_command_streaming (~line 697)

Severity: Medium (surprising behavior)

ABSOLUTE_TIMEOUT_SECONDS = 270

Every foreground shell command is hard-killed after 270 seconds, regardless of the timeout parameter the agent passed. The timeout arg only controls the inactivity timeout; the absolute cap is a hidden module constant that:

• is not mentioned in the agent_run_shell_command tool docstring (which advertises timeout: int = 60 as if it were the only knob), so the model reasonably believes timeout=600 buys 10 minutes;
• kills legitimately long, actively-printing jobs (test suites, builds, downloads) at 4.5 minutes even though they're producing output;
• returns exit_code=-9, timeout=True, error="Command timed out after {timeout} seconds" - which reports the inactivity number, not the 270s that actually triggered, so the message lies about what happened (cleanup_process_and_threads receives timeout_type but doesn't use it in the error string).

Explicit is better than implicit. Suggested fix:

1. Make the absolute cap configurable (config key or parameter), or derive it from the caller's timeout (e.g. max(270, timeout * N)).
2. Include the actual limit and timeout type in the returned error string: f"Command killed by {timeout_type} timeout after {limit}s".
3. Document both timeouts in the tool docstring so the model can choose background=True for long jobs instead of being mystery-killed.

Filed by Zen Reviewer B (code-puppy-60635a)

Start in code_puppy/tools/command_runner.py at run_shell_command_streaming around line 697, then follow cleanup_process_and_threads and the agent_run_shell_command tool docstring. Trace how the inactivity and absolute timeouts are selected and reported. Done means the cap behavior is explicit or configurable, the error identifies the actual timeout type and limit, and both timeouts are documented.