[eyeveil]

Problem

When an agent calls t3_environment_link, its link card marks the thread as waiting for input. #28491 made the card stop counting once the user writes in the thread again, but it counts only messages with createdBy: "user". Threads that agents drive, through subagent notifications, coordination messages from other threads, or a thread started over MCP, may never get one. They stay on Input for good while every pending-request list is empty.

To reproduce, have an agent ask for a link and end its turn. Then start another turn with an agent-authored message, for example t3 thread send. The thread finishes but still shows Input, and t3 thread show reports pendingRequestCount: 0. In the thread where this surfaced, a card asked 53 runs earlier kept the thread on Input. A watcher keyed on that status also re-reported "asks a question" on every new run.

Change

The card now stops counting once any user-role message newer than it arrives, whoever sent it. Idle compactions still don't count. Both shell paths (threadShellFromProjection and the SQL shell row) and the auto-settle query from #29847 use the same rule. A thread that reads as done can therefore also settle. The card stays pending and answerable in the timeline. Secret cards are unchanged.

Scope and approval

This is a very small, focused fix for an obvious bug. It finishes the rule #28491 introduced for threads that no person types into, and it changes one comparison in three places that must agree. It is server-only. Web, desktop, and mobile read pendingRuntimeRequest from the shell, so they pick it up with no client changes. #26944 is related but separate. It ends a card after a matching retry links, and in this case no retry happened.

Verification

• The existing the agent asks without waiting… case in PeerLinkRequests.test.ts now writes an agent-authored message past the card. On main it fails with expected { …(4) } to be null at the shell assertion. With the fix, it passes, and the settlement assertion after it passes too.
• PeerLinkRequests.test.ts, ProjectionSettlement.test.ts, and ThreadSettlementService.test.ts pass 58/58.
• On a dev server with fixture data, a thread had a waiting card and then a turn started by an agent message. Before the fix, the sidebar showed Input. After it, the sidebar shows Done.
• Not checked: a real link flow between two machines. The test drives the real PeerLinkRequests service against a served peer.

Before	After

Model and harness: Claude Opus 5.5 (lead, implementation) via Claude Code in T3 Code.

[macroscopeapp]

Approvability

Verdict: Approved at e0aa293

Macroscope's review found this PR approvable — Link cards now stop asking after a newer user-role message, including agent-authored messages, keeping thread status and settlement eligibility consistent. Existing active-run and settlement safeguards remain unchanged.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

Waiting link request cards now use any non-idle-compaction user message as activity that dismisses the card. The shell state separately tracks the latest user message and the latest user-authored message. The peer-link test now covers a later agent-created message.

Changes: Link request activity

Layer / File(s)	Summary
Apply thread activity to waiting link requests apps/server/src/orchestration-v2/ProjectionStore.ts, apps/server/src/peer/PeerLinkRequests.test.ts	Projection derivation, shell filtering, and settlement selection use the latest user message to evaluate waiting link requests. The test fixture uses a later agent-created message.

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Possibly related issues

• pingdotgg/t3code#28384 — The issue reports that waiting link cards can keep a thread on Input after a machine links. This change updates when waiting cards count toward Input and settlement, but does not close or resolve the cards.

Suggested reviewers: georgenijo, saphid

Merge Risk: Minimal · up to e0aa2

No merge-blocking risk was identified. Link cards remain answerable after the thread settles.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title describes the link card fix. The rule applies to newer user-role messages regardless of author, except idle compactions.
Description check		The description covers the problem, change, scope, and verification. It includes screenshots, an unchecked scenario, and the model and harness.
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Finishing Touches

Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Tip

🎯 Customize your risk assessments

Guide how CodeRabbit assesses merge risk and security architecture risk. Highlight sensitive changes and explain your security boundaries using Merge Risk Instructions and Security Risk Instructions in your review settings. Security architecture risk assessments require the Advanced plan or above.

✅ Automatic approvals, with your rules

Let CodeRabbit approve pull requests once required threads are resolved, pre-merge checks pass, and your risk limits are met. Enable Automatic approvals in review settings, with overrides for teams or file paths.

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: e455200
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: a034bf40-2522-4384-ab28-d623c3cca1ed

Commits

Reviewing files that changed from the base of the PR and between e455200 and e0aa293.

Files selected for processing: 2

• apps/server/src/orchestration-v2/ProjectionStore.ts
• apps/server/src/peer/PeerLinkRequests.test.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

[eyeveil]

Note

Written by claude-opus-5-5 on behalf of eyeveil

Moved to #32473, the same commit from a personal fork. This PR came from the organization-owned issuelt/t3code fork, and GitHub lets maintainers push only to PR branches in personal-account forks, so maintainer edits here failed with 403. Closing in favor of #32473.