config: raise code agent timeout to 60 minutes - #7222
Conversation
The code agent runs on runtime pi with model xai/grok-4.6, which is slower than the sonnet/opus defaults the other agents use. On issue fullsend-ai#7218 the run implemented the change in full and staged 16 files (806 insertions) but was killed at the base harness's 35-minute budget before it could commit, so no PR was opened. Override timeout_minutes to 60 on the code agent so grok-4.6 has room to finish and commit within a single iteration. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: Greg Allen <gallen@redhat.com>
PR Summary by QodoRaise code agent timeout to 60 minutes
AI Description
High-Level Assessment
Files changed (1)
|
Code Review by Qodo
1. The code agent still stops at the 35-minute limit
|
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
| - name: code | ||
| runtime: pi | ||
| model: xai/grok-4.6 | ||
| timeout_minutes: 60 |
There was a problem hiding this comment.
1. The code agent still stops at the 35-minute limit 🐞 Bug ≡ Correctness
The timeout_minutes key is added to the code agent entry, but config.AgentEntry has no corresponding field and the YAML loader does not reject unknown keys. When this repository loads the configuration, the value is discarded, so the harness continues using its base timeout instead of the requested 60 minutes.
Agent Prompt
## Issue description
The new `timeout_minutes: 60` setting is not consumed by this repository. `internal/config.AgentEntry` only models runtime, model, effort, and subagents, while YAML loading accepts unknown keys, so the setting is discarded and the code agent keeps the inherited 35-minute timeout.
## Fix Focus Areas
- .fullsend/config.yaml[24-27]
- internal/config/config.go[51-65]
- internal/config/config.go[500-520]
## Recommended Fix
Add a typed timeout field to the agent configuration model, validate its allowed range, preserve it through layered configuration merges, and pass it to the agent/harness execution path. Add tests proving that `timeout_minutes: 60` survives parsing and effective-config resolution; alternatively, do not add this repository-level key until the consuming configuration support exists.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| - name: code | ||
| runtime: pi | ||
| model: xai/grok-4.6 | ||
| timeout_minutes: 60 |
There was a problem hiding this comment.
2. Agent still stops at 35 minutes 🔗 Cross-repo conflict ≡ Correctness
The repository overrides timeout_minutes to 60, but the pinned fullsend-ai/agents code harness still injects TIMEOUT_SECONDS=2100 into the sandbox. The code implementation skill reads that variable for its deadline checks, so the agent can stop at 35 minutes before the Fullsend runner's 60-minute timeout and still fail to commit.
Agent Prompt
## Issue description
The local configuration raises the runner-level code-agent timeout to 60 minutes, but the pinned `fullsend-ai/agents` code harness still sets `TIMEOUT_SECONDS` to 2100 seconds. The code implementation skill uses that sandbox variable for its time-budget checks, so the agent may still terminate after 35 minutes.
## Fix Focus Areas
- .fullsend/config.yaml[24-27]
- /cross_repos/agents/harness/code.yaml[75-85]
- /cross_repos/agents/skills/code-implementation/SKILL.md[68-90]
## Recommended Fix
Update the code harness's sandbox `TIMEOUT_SECONDS` to `3600` alongside `timeout_minutes: 60`, then update the pinned harness/source reference or otherwise ensure this repository consumes the synchronized `fullsend-ai/agents` change. Add or update integration coverage so both the runner timeout and the sandbox deadline remain aligned.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
|
🤖 Finished Review · ✅ Success · Started 9:00 PM UTC · Completed 9:13 PM UTC Commit: Runtime: pi · Model: sonnet → claude-sonnet-5 · Effort: high · Cost: $2.54 |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
|
Risk Assessment: moderate (2/5) Details1-file, 1-line config change with minimal Tier 1 risk (no protected/security-sensitive paths, no CI/dependency changes), but the touched file (.fullsend/config.yaml) is a high-churn, multi-author hotspot (Tier 2 ~2/5), and the linked issue (#7218) is topically unrelated to the change, relying instead on the PR body's own rationale (Tier 3 ~3/5). Weighted composite (0.51 + 0.32 + 0.2*3 = 1.7) rounds to 2 (moderate). |
ReviewFindingsHigh
Medium
Next steps:
|
![fullsend-ai-review[bot]](https://avatars.githubusercontent.com/in/3478501?s=60&v=4){kind=small}
| - name: code | ||
| runtime: pi | ||
| model: xai/grok-4.6 | ||
| timeout_minutes: 60 |
There was a problem hiding this comment.
[high] runtime-mechanism
timeout_minutes: 60 on the code entry in the per-repo agents: list has no runtime effect. config.AgentEntry (internal/config/config.go) has no TimeoutMinutes field, and its UnmarshalYAML decodes via plain yaml.v3 Decode with no KnownFields(true), so the unknown key is silently dropped. applyAgentSettings (internal/cli/run.go) only copies Model and Effort from a config AgentEntry onto the resolved harness — never a timeout. The actual per-iteration budget comes from the harness-level Harness.TimeoutMinutes field, which this override-only agent entry (no source:) never touches. docs/reference/config-reference.md's documented agents: fields also omit timeout_minutes. As written, the code agent keeps the base harness's 35-minute budget and the exact failure the PR describes (killed near the 35-minute mark before git commit) will recur.
Suggested fix: Create a local harness override (e.g. harness/code.yaml) with base: <upstream code.yaml>#sha256=... and timeout_minutes: 60, then register it in .fullsend/config.yaml via source: harness/code.yaml (dropping the inert timeout_minutes: key from the override-only entry). Alternatively, add a validated TimeoutMinutes field to config.AgentEntry and wire it into applyAgentSettings/harness composition.
|
The diagnosis here is right, but this key won't take effect — it parses cleanly and is then dropped.
Nothing in The supported mechanism is
base: https://raw.githubusercontent.com/fullsend-ai/agents/<sha>/harness/code.yaml#sha256=<digest>
timeout_minutes: 60
- name: code
runtime: pi
model: xai/grok-4.6
source: harness/code.yamlScalars are child-wins, so One prerequisite: a URL Worth deciding separately where the 60 belongs. The overlay scopes it to this repo, which matches the reasoning in the description, since the slower runtime is a choice this repo makes. Raising it in |
|
Closing in favor of fixing this at the source: the code agent's 35-minute budget is set in the base harness (fullsend-ai/agents |
|
🤖 Finished Retro · ✅ Success · Started 9:23 PM UTC · Completed 9:28 PM UTC Commit: Runtime: claude · Model: sonnet → claude-sonnet-5 · Effort: high · Cost: $0.84 |
|
PR #7222 tried to fix the code-agent timeout kill from issue #7218 by adding Proposals filed
|
2 participants
What
Adds
timeout_minutes: 60to thecodeagent entry in.fullsend/config.yaml, overriding the base code-agent harness default of 35 minutes (fullsend-ai/agents→harness/code.yaml).Why
This repo overrides the code agent to
runtime: pi/model: xai/grok-4.6, which is slower than thesonnet/opusdefaults the other agents use. On #7218, the code agent (run 34516625497) implemented the change in full — 16 files, 806 insertions — and staged everything, but was killed at the 35-minute budget ~17s beforegit commit. No commit meant no PR, and the run was misreported as "✅ Success / no changes needed" (tracked separately in fullsend-ai/agents#1256).Raising the code agent's budget to 60 minutes gives grok-4.6 room to finish and commit within a single iteration.