Repository navigation
Automatically resume agent thread on CI/check failure #10717
Description
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:
- architecture-specific builds/tests (ARM64, different CPU features, etc.)
- OS-specific jobs (Linux/macOS/Windows)
- containerized or service-heavy integration environments
- tests that depend on infrastructure, secrets, external services, or hosted runners
- larger CI matrices that would be impractical to run locally
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:
- After the agent pushes a commit, monitor the checks for that PR/HEAD SHA.
- If a check fails, fetch the failed check metadata and relevant logs/output.
- Inject the failure into the existing thread as new context/event.
- Automatically resume/wake the agent so it can diagnose and fix the failure.
- After the agent pushes a new commit, ignore failures/results belonging to obsolete SHAs.
- Continue until the latest commit is green, or until the agent/user stops the workflow.
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 reruns
The 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.
Activity
juliusmarminge commentedon Sep 8, 2026
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
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.monitor_startcommand output. Related wake path; not CI.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:
thread.turn.starton the existing thread.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).