Repository navigation
Automatically resume agent thread on CI/check failure #10717
Description
Activity
Triage
This is a real product gap, not a bug in current behavior.
T3 Code already links a thread to a branch/PR (
ThreadPullRequestReactor) and can show check rollups in the PR UI. It does not subscribe to check state, fetch failure logs, inject that into the thread, or start a new turn when CI fails. The sidebar Monitoring pill is provider watch-loop liveness (the agent pollinggh, tailing logs, or using a monitor tool). That is the opposite of what this issue asks for: T3 as the event source.Closest prior work
- Add PR monitoring: server-driven babysit mode for agent threads #4428 (closed, not merged) implemented server-driven PR babysit:
monitor_start, ~30s GitHub poll, SHA-anchored check/review diffs, wake viathread.turn.start, obsolete-SHA / readiness guards. Closed because orchestrator V2 (feat(orchestrator): introduce new orchestrator #2829, still open) moved the base; Julius noted the gaps are still wanted and would need a port, not a rebase. - feat(infra): add github pr event feed #7403 (closed) added a standalone GitHub webhook/SSE feed so babysitters would not poll. Closed as more infra than T3 needs for current operation — do not start here.
- feat(codex): wake threads from background monitoring events #10183 (open) wakes Codex threads from local
monitor_startcommand output. Related wake path; not CI. - [Bug]: "Monitoring" notification hides "Compact" notification #10164 / [Bug]: iOS does not show Monitoring status displayed on desktop and web #10372 are UI bugs around the Monitoring notice. Same word, different feature.
No open or merged PR implements this.
Suggested direction
Treat this as an accepted enhancement. A first cut should look like #4428, not automatic resume on every push of every linked thread:
- Opt-in babysit (agent or user starts watching a linked PR).
- Server watches HEAD SHA checks (poll or host CLI; no new webhook service).
- On failure, fetch metadata + bounded logs and dispatch
thread.turn.starton the existing thread. - Drop results for superseded SHAs; stop on user settle/stop, circuit breaker, or green HEAD.
Automatic-on-every-push is a later product call (cost, surprise wakes, stopped/snoozed threads). GitLab / Bitbucket / Azure DevOps already expose check rollups and would each need an explicit “supported / not here” decision.
Labels:
enhancement,accepted,via-triage(removeneeds-triage).- Add PR monitoring: server-driven babysit mode for agent threads #4428 (closed, not merged) implemented server-driven PR babysit:
Problem
T3 Code can already work with GitHub/PR state, but CI handling still appears to rely on the agent actively polling/checking status.
For long-running coding tasks, it would be much more useful if T3 Code itself could monitor the PR/check state and push failures back into the existing agent thread when they happen.
This is especially important for projects where CI runs tests that cannot realistically be reproduced in the local development environment, for example:
In those cases, CI is not just a final verification step; it is effectively part of the development feedback loop. The agent needs the failure output in order to continue the task.
Proposed behavior
When a thread is associated with a branch/PR:
Why
This would avoid spending agent turns repeatedly polling GitHub and would make the workflow genuinely event-driven:
push -> CI runs -> failure arrives -> existing agent thread resumes -> fix -> push -> CI rerunsThe important distinction is that T3 Code should be the event source here rather than requiring the agent to periodically ask GitHub whether CI has completed.
It would also make external signals such as CI failures behave more like first-class inputs to a running agent session, which seems useful beyond GitHub Actions as well.