Repository navigation
Conversation
github-actions
Bot
added
size:S
![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 focused fix to the existing optional Working-shelf classification, keeping threads with live background commands visible there while preserving inbox treatment for failures and user-action states. The change is self-contained and covered by targeted tests, with no schema, infrastructure, security, or default-setting impact. You can add or adjust custom eligibility rules. Learn more. |
|
Important Review skippedWe couldn't safely recover the incremental review. No full review was started, and the last reviewed checkpoint was preserved. Retry later, or explicitly request a full review by commenting You can disable this status message by setting the Use the checkbox below for a quick retry:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to
|
| Check name | Status | Explanation | Resolution |
|---|---|---|---|
| Docstring Coverage | Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 2 functions across 3 files. | Write docstrings for the functions missing them to satisfy the coverage threshold. | |
| Description check | The description covers the problem, change, cases, and verification. However, the Scope and approval section states that maintainer sign-off is missing, while the template requires explicit approval f… | Add a link to a discussion comment that explicitly approves the direction and scope. If the change qualifies for the small, focused obvious-bug exception, explain why. |
✅ Passed checks (3 passed)
-
Check name Status Explanation Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request. Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request. Title check ✅ Passed The title clearly summarizes the main change: background commands keep threads in the Working section.
Full details: Description check
-
Explanation
The description covers the problem, change, cases, and verification. However, the Scope and approval section states that maintainer sign-off is missing, while the template requires explicit approval for this behavior change.
✨ Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Create a new PR
-
- Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Comment @coderabbitai help to get the list of available commands.
b674ab8 to
2da72ef
Compare
2da72ef to
cb01071
Compare
… stays in Working Port of pingdotgg/t3code#15413. T3's Working check counts background work only when it parks the runtime at idle, and #14872 stopped commands from doing that, so a thread whose agent waits on a background Bash dropped into the inbox. The patch counts any live background task; a failed run, an approval, a question or a ready plan still go to the inbox.
|
Note Written by Thanks for documenting the background-command case. This makes completed threads with dev servers stay in Working, changing the intentional command exception without maintainer approval. Intentional product behavior changes require prior approval. Please use discussion #15433 to agree on the intended behavior and scope before requesting reconsideration. |
2 participants
When an agent leaves a background command running and ends its turn, the composer shows "Running: ..." with a Stop button. With the Working section beta on, that thread still drops into the inbox as if it were done. I hit this with a Claude thread that started a background Bash to wait out a lockout and then rerun QA. The agent was waiting on that command, but the thread looked finished.
The cause is
isThreadWorkinginpackages/client-runtime/src/state/threadInbox.ts. It only counts background work that parks the runtime atidle, and #14872 made commands stop parking it. Subagents, monitors, and other background tasks already land in Working. Commands do not.This PR makes
isThreadWorkingtreat any live background task as work. Web and mobile both call it, so one change covers both. Notifications, idle parking, and auto-settle keep the #14872 rule. A failed run, an approval, a question, or a ready plan still keeps the thread in the inbox.Trade-off: a dev server left running keeps its thread in Working until you stop it. The thread does return to the top of the inbox when the command ends.
Before / after
Same live thread (Claude Sonnet 5.5 ran
sleep 1800withrun_in_background, then ended its turn). Working section beta on. The only difference isthreadInbox.ts.While the turn is still running, the row is already in Working on both main and this PR. The difference is only what happens after the turn ends.
Mid-turn (same on main and this PR)
Cases
Verification
vp test run packages/client-runtime/src/state/threadInbox.test.ts apps/web/src/components/Sidebar.logic.test.ts: 146 passed. New cases cover each background kind (command, monitor, subagent, background_task) and a failed run with a live command.vpr typecheckpasses inpackages/client-runtime,apps/web, andapps/mobile.Not checked: the mobile Working section in a simulator. It calls the same function.
Approval
This changes how the Working section beta treats commands, which #14872 decided on purpose. I have not had maintainer sign-off on the direction. Discussion: #15433. If you'd rather keep commands out of the Working section, close this and I'll drop it.
Claude Opus 5.5 via Claude Code in T3 Code.