Add support for per-prompt execution timeout (prompt_timeout_seconds)

[graceqi-g]

Supports setting prompt_timeout_seconds across Agent CLI generators (gemini_cli, claude_code, codex_cli, agy_cli) to terminate prompt turns that spin indefinitely. Configurable per scenario JSON, per model YAML, or per run_config YAML.

Order of precedence from highest priority to lowest is scenario, model, then run config.

[graceqi-g]

/gcbrun

[prernakakkar-google]

/gcbrun

[prernakakkar-google]

proc.stdout.readline() is a blocking call. If the subprocess stalls mid-line (never emits a newline) rather than between lines, the timeout check on the while True loop never gets revisited until the next line arrives the timeout is only enforced between lines, not truly wall-clock bounded. Consider using non-blocking reads (e.g., select, a reader thread with a queue, or proc.stdout.readline wrapped with signal.alarm/asyncio) to guarantee the kill happens within timeout regardless of the subprocess's I/O behavior.

[graceqi-g]

added threading.Timer to ensure the timeout is enforced

[graceqi-g]

/gcbrun

[graceqi-g]

/gcbrun

[graceqi-g]

/gcbrun

[prernakakkar-google]

/gcbrun

[prernakakkar-google]

Neither subprocess.run(..., timeout=...) (gemini/claude/agy) nor proc.kill() (codex) kills the process group — only the direct child. These agent CLIs are node-based and routinely fork subprocess trees (MCP servers, tool subprocesses). On timeout, grandchildren can be orphaned and keep running, holding ports/CPU/memory. Across a long eval run with repeated timeouts, this can accumulate

[prernakakkar-google]

subprocess.TimeoutExpired carries the output captured so far on e.stdout / e.stderr, but the handlers hardcode "":

except subprocess.TimeoutExpired:
    return subprocess.CompletedProcess(command, 124, "", f"Error: ...")

This is inconsistent with the Codex path, which preserves stdout_lines. More importantly, it contradicts the existing design intent in agy_cli._run_agy_cli, whose own comment says "a timed-out/errored run still ends in a result event carrying real data" — but with a hard subprocess.run timeout, that stream is thrown away, so the partial trajectory/tool calls before the hang are lost.
This is happening for agy/claude/gemini cli

[graceqi-g]

Neither subprocess.run(..., timeout=...) (gemini/claude/agy) nor proc.kill() (codex) kills the process group — only the direct child. These agent CLIs are node-based and routinely fork subprocess trees (MCP servers, tool subprocesses). On timeout, grandchildren can be orphaned and keep running, holding ports/CPU/memory. Across a long eval run with repeated timeouts, this can accumulate

Added logic to try killing the process group first

subprocess.TimeoutExpired carries the output captured so far on e.stdout / e.stderr, but the handlers hardcode "":

Updated the handlers to output stdout if nonempty and stderr

[graceqi-g]

/gcbrun