Prompt timeout default is too short for codex_cli_write agents

[samleeney]

Problem

Flows currently applies the same default prompt timeout to all prompt nodes:

• pkg/runtime/prompt.go: DefaultPromptTimeout = 2 * time.Minute
• cmd/flow/run.go: --llm-timeout defaults to that value
• pkg/runtime/codex.go: codex exec is run under the same timeout context

That is reasonable for small API prompt nodes, but it is too short for codex_cli_write agents. Those agents may inspect a repository, reason over a large context, edit files, and return a final patch summary. In practice they can easily need more than two minutes.

Observed failure mode

In a long-running Flow with this shape:

1. deterministic context/setup nodes
2. a long C3/GPU validation job
3. baseline_evaluate emits baseline_pass
4. speed_iteration_context builds a large context
5. speed_iteration_agent uses prompt_executor: codex_cli_write

The baseline C3 job completed successfully and wrote valid artifacts, but the flow stopped before the first speed iteration was recorded:

• baseline validation existed and passed
• speed_attempts.txt stayed at 0
• speed_history.json stayed empty
• no speed-attempt C3 job was submitted

The deterministic speed context block can be reconstructed successfully from disk, so the likely failure point is the first codex_cli_write prompt call timing out before it can apply a patch or emit downstream state.

Why this is a problem

A two-minute default makes complex write-agent flows fail in a way that looks like the graph did not advance. It is especially confusing when a previous deterministic node ran for a long time and succeeded, because the next LLM edit node can abort quickly relative to the rest of the flow.

The foreground terminal may show the failure, but unless the user tees logs or passes --output, the persisted flow state does not make the prompt timeout obvious.

Expected behavior

codex_cli_write should have timeout behavior appropriate for agentic edit work, not the same small default as lightweight prompt/API calls.

Possible fixes:

1. Give codex_cli_write a separate, much longer default timeout than normal prompt calls.
2. Add per-node YAML timeout support, for example:

prompt_executor: codex_cli_write
timeout: 30m

3. Persist failed node status/error in run state or output artifacts so a timed-out prompt node is visible after the terminal exits.
4. Make the UI show the failed node and timeout reason clearly for foreground and background runs.

Workaround

Run long write-agent flows with an explicit timeout, for example:

flow run my_flow.md -f --llm-timeout 24h

This works, but it is too easy to forget and applies globally rather than expressing the timeout where the long-running node is declared.