[Bug]: orca exec exits 4 (BudgetExhausted/max inner turns) mid-task on long runs - hardcoded 128-turn cap, not configurable, trajectory lost

[echoVic]

Orca version

0.3.7 (commit 6088d85)

Installation method

Built from source (musl cross build)

Platform

Linux container (Terminal-Bench task env), harbor 0.20.0, deepseek-v4-flash, orca exec --mode full-auto --output-format jsonl

Mode

orca exec (headless, under harbor)

Steps to reproduce

Run a long task (e.g. Terminal-Bench terminal-bench/fix-ocaml-gc or terminal-bench/winning-avg-corewars) with orca exec. Observed in the 0.3.7 full benchmark run:

harbor.trial.errors.NonZeroAgentExitCodeError: Command failed (exit 4): orca exec --mode full-auto --output-format jsonl '...'

Expected behavior

A long-running session should not be silently terminated by an invisible turn cap; if a limit exists it should be configurable, documented, and exit with a distinguishable code that preserves the trajectory.

Actual behavior

• orca exec exits with code 4 = RunStatus::BudgetExhausted (event_schema.rs: BudgetExhausted => 4).
• With no --max-budget configured, the only producer is the hardcoded inner-turn cap: agent_loop.rs DEFAULT_MAX_TURNS: u32 = 128, enforced in lifecycle.rs start_turn (if self.turns_started >= self.max_turns { BudgetExhausted / MaxInnerTurns }).
• The turn cap is not configurable: no CLI flag and no config-file field (searched src/cli.rs and crates/orca-core/src/config).
• Evidence from the 0.3.7 full run (both tasks passed in the 0.3.4 run with trajectories of 82-99 turns):
  • terminal-bench/fix-ocaml-gc: exited 4 after only 37.6 min of its 3600s agent budget — the agent was mid-work and got cut off.
  • terminal-bench/winning-avg-corewars: exited 4.
  • Both trials lost their trajectory (the non-zero-exit path skips the trajectory.jsonl write, see the gap noted in issue [Bug]: 063b47cd8 fix crashes every Terminal-Bench trial - AgentContext has no 'output' field (verifier never runs) #25), so the exact turn count of the failed runs is unverifiable — only the exit code and early-exit timing remain.

Additional context

Suggested fixes (any combination):

1. Expose max_turns as a CLI flag (--max-turns) and/or config.toml field, defaulting to 128.
2. On turn-limit exhaustion, write the trajectory before exiting (or use a distinct exit code and ensure the adapter persists stdout regardless of exit code).
3. Surface a warning/event when the limit is approached so headless users know the run was cut off, not completed.

[echoVic]

Additional evidence from the v0.3.14 full benchmark run (89 tasks, k=1, same setup as before):

exit 4 occurrences are increasing across versions: 0.3.4 → 0 / 0.3.7 → 2 / 0.3.14 → 4 (plus one exit-4 case where the verifier happened to pass):

task	0.3.4	0.3.7	0.3.14
fix-ocaml-gc	1 (pass)	exit 4	1 (pass)
winning-avg-corewars	1 (pass)	exit 4	timeout
make-mips-interpreter	timeout	timeout	exit 4
video-processing	exit 137	1 (pass)	exit 4
sam-cell-seg	fail	fail	exit 4
regex-chess	timeout	1 (pass)	exit 4 (verifier 4/4 passed)

The regex-chess case is the clearest evidence that the cap cuts off completed work: the session was terminated at turn 128 with exit 4, yet the verifier still passed 4/4 — the task was done, the agent just was not allowed to stop normally.

v0.3.8-v0.3.14 features (side conversations, background task fencing, cache-prefix identity) plausibly increase per-task turn consumption, making the hardcoded 128-turn cap hit more often. Scored pass rate (excluding env losses): 0.3.4 64.8% → 0.3.7 63.5% → 0.3.14 62.4%, with the exit-4 count the most visible structural change. The fix (configurable/exposed max_turns, or graceful exit preserving trajectory) remains open.