Repository navigation
Conversation
Auto-settlement reused the completion-alert rule, which ignores pending background commands. A Claude background Bash the agent is waiting on wakes the agent when it exits, so the thread settled while it was still working. Any live pending background task now holds auto-settle. Alerts and sidebar status keep their rule.
github-actions
Bot
added
vouch:unvouched
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
ApprovabilityVerdict: Approved at Macroscope's review found this PR approvable — This is a narrowly scoped, well-tested bug fix that prevents auto-settlement while any background task can still wake the agent, without changing configured default values or unrelated runtime behavior. The documentation accurately describes the intentional delay for long-lived commands. You can add or adjust custom eligibility rules. Learn more. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configuration
📒 Files selected for processing (3)
Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review. 📝 WalkthroughWalkthroughAutomatic settlement now excludes a thread while any background task is pending. Tests cover merge-based and inactivity-based settlement. Sidebar documentation describes that a running background command blocks automatic settlement until it exits or the thread is settled manually. ChangesAuto-settlement
Priority: ➖ Normal Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix · Severity of issue fixed: Medium Suggested reviewers: Merge Risk: ⚪ Minimal · up to Threads with a running background command stay unsettled until the command exits or the user settles them manually. The PR describes this as intended, and the docs are updated. No merge-blocking risk was found. Architecture SummaryArchitecture risk: 🔵 Low · up to The change affects 2 systems. Changed systems: Architecture concerns Review detailsSystems and components
Before / after behavior
Pre-merge checks |
 |
| Check name | Status | Explanation |
|---|---|---|
| Linked Issues check |  |
Issue #17625 requires auto-settlement to wait for live pending background work under both merged-PR and inactivity rules. isAutoSettlementCandidate now rejects any non-empty pendingBackgroundTasks… |
| Out of Scope Changes check | |
The changes stay within issue #17625. The server change updates only the auto-settlement gate. The tests cover the required command and settlement-rule behavior. The documentation explains the resulti… |
| Title check | |
The title clearly identifies the server and documentation change: auto-settlement now waits while a background command runs. |
| Description check | |
The description covers the problem, change, scope, trade-off, verification results, and related issues. It also states the unverified end-to-end check. The focused-fix rationale adequately addresses t… |
✨ Finishing Touches
🧪 Generate unit tests (beta)
- Create a new PR
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Comment @coderabbitai help to get the list of available commands.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
|
Note Written by Hi! We are cleaning up open PRs, and this one does not say which model or harness was used to create it. If this change is really important, we recommend rebuilding the PR with a newer model and noting the model and harness in the PR description. |
|
Reopened as #18062 with the model and harness noted: Claude Opus 5.5 via t3code. |
|
Note Written by Reopening, this was closed by mistake. Sorry for the noise! |
2 participants
Fixes #17625
Related: #15099 (the completion alert for the same case, which this PR leaves unchanged) and #15413.
Problem
A thread auto-settles while the agent is still waiting on a live background command. Claude records every background Bash as a pending task of kind
command, and the CLI wakes the agent when that command exits. Auto-settlement reused the completion-alert rule,backgroundWorkHoldsCompletion, which treats acommandas "the agent is done". When the merge rule or the inactivity rule came due, the thread settled while the composer still showed the command running, and the agent later woke up in a settled thread.Change
isAutoSettlementCandidatenow rejects a thread with any live pending background task, whatever its kind. That one check covers both the settlement sweep andresolveAutoSettlementAt, so the merge rule and the inactivity rule both wait. Completion alerts and sidebar status keep their current rule, so a dev server left running still lets the "done" notification fire.The user guide's auto-settle section now says a background command holds the thread until it exits.
Trade-off: a thread with a dev server or another long-lived command left running stays unsettled until the command exits or the user settles the thread by hand. Auto-settle is silent and hides the thread, so holding it a little too long is the cheaper mistake.
Scope and approval
This fixes the bug reported in #17625, using the fix that issue suggests. It changes only the auto-settlement gate on the server, plus its tests and one sentence of user docs.
Verification
Replaced the test that expected a live
commandto allow auto-settle with one that expects it to hold the thread. Added a test where a thread with a livecommanddoes not settle under either the merged-PR rule or the inactivity rule, and the same thread with no pending tasks settles under both. Both new tests fail with the old check and pass with the fix. The existing settlement service and settlement projection tests still pass, and the server package typechecks. I did not reproduce the bug end to end in a running app.Written by Claude Opus 5.5 via t3code. This PR was opened by Grok Bot.