[georgenijo]

When an agent calls t3_environment_link, it asks without waiting, so its link card keeps the thread on "Input" after the run ends. Nothing closed that card except answering it, stopping, or archiving. If the user ignored it and kept chatting, the thread kept showing "Input" for every later turn, even when it was finished. In the thread that surfaced this, the card was asked 30 turns earlier and the user had to ask "does something need my approval?"

A waiting link card now stops flagging the thread once the user writes in it again (a newer user-authored message than the card). The card stays pending and answerable in the timeline. Secret cards are unchanged, since they only count while their run is live. Both shell paths (threadShellFromProjection and the SQL shell row) apply the same rule. The SQL latest_user_authored_message_at subqueries now skip idle compactions, matching the in-memory path, so an automatic compaction can't count as the user moving on.

Verification:

• Extended the agent asks without waiting… in PeerLinkRequests.test.ts: after the run ends and the user writes again, both shell paths report no pending input and the card is still pending. It fails on main and passes with the fix. The rest of the test still answers that card.
• PeerLinkRequests.test.ts, ProjectionStore.test.ts, and ThreadSettlementService.test.ts pass. vp run check:changed is green.
• An independent gpt-5.6-sol review found the idle-compaction parity gap, which is fixed here. Its recheck passed.

Surfaces: server-only. Web, desktop, and mobile read pendingRuntimeRequest from the shell, so all of them pick this up with no client changes. Settlement and the may_be_live superset are intentionally unchanged.

Done by Claude Opus 5.5 in Claude Code, running in T3 Code.

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at 31f5c5a

Macroscope's review found this PR approvable — Old link cards stop keeping a thread marked as awaiting input once the user continues chatting. This changes derived status only; cards remain answerable and blocking requests retain their existing handling.

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

[coderabbitai]

No actionable comments were generated in the recent review.

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: 549b651
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: c143d036-2187-4d85-8be0-baef32513b1b

Commits

Reviewing files that changed from the base of the PR and between 549b651 and 31f5c5a.

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.

Walkthrough

Waiting link-request cards no longer count as pending user input when a qualifying user-authored message is later than the card’s start time, or its update time when no start time exists. Shell views apply this check. Secret-request handling remains based on whether its run is live.

Changes: Link request pending state

Layer / File(s)	Summary
Evaluate waiting link requests in shell views apps/server/src/orchestration-v2/ProjectionStore.ts, apps/server/src/peer/PeerLinkRequests.test.ts	Shell construction and SQL-backed reads use the latest non-idle-compaction user message timestamp to filter waiting link requests. The test verifies that both shell views report no pending runtime request while the card remains waiting and pending.

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

Change: Bug fix

Suggested labels: bugfix

Suggested reviewers: juliusmarminge, t3dotgg

Merge Risk: Minimal · up to 31f5c

No actionable merge-blocking risk was identified for the pending link-card behavior.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title clearly and concisely describes the main fix: an old link-request card no longer keeps a thread flagged for input.
Description check		The description covers the problem, implementation, affected shell paths, verification results, scope, and agent details. It is mostly complete, although it does not explicitly link a bug or maintaine…
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.

Full details: Description check

Explanation

The description covers the problem, implementation, affected shell paths, verification results, scope, and agent details. It is mostly complete, although it does not explicitly link a bug or maintainer approval, or explain the obvious-bug exemption.

Finishing Touches

Generate unit tests (beta)

• Create a new PR

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

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

Verified in a real dev environment

verified as-is at 31f5c5a100c94f115960b7e7aa39d192c8669426 on a disposable linux vm. no code changes or pushes.

ran github/main (7195b69954) first in a separate worktree, then stopped it and ran the exact pr head. used the dev web app with repository playwright and /usr/bin/google-chrome. created a local git project through the app, enabled linked environments in settings, and sent real codex gpt-6.1-sol turns through the local proxy. no mocks, fixtures, or replay provider.

• main reproduced the bug: the agent requested an environment link, finished, and completed another user turn, but the sidebar still showed "input".
• the pr cleared "input" on the same app-created thread and transcript, copied after main stopped. the unanswered card stayed visible and enabled.
• a fresh link request on the pr still showed "input" after its turn finished. another user message cleared it through the live client update.
• the old card's machine picker still opened. declining that old card persisted linkStatus: "declined" and delivered its outcome to a real codex turn. the newer card remained waiting / pending.
• a page reload preserved the cleared status and enabled remaining card.

short runtime transcript from authenticated requests through the running web client (x-t3-orchestration-protocol: 2):

GET /api/orchestration/shell -> 200
same saved thread on pr: status=completed, pendingRuntimeRequest=null
fresh codex link request: pendingRuntimeRequest.kind=user_input, blocking=true
continued user turn: sidebar input cleared
old-card decline: status=cancelled, linkStatus=declined
remaining card: status=waiting, linkStatus=pending
reload -> status=completed, pendingRuntimeRequest=null, remainingCardAnswerable=true
all five real codex runs: completed

blacksmith passed the 92 tests in PeerLinkRequests.test.ts, ProjectionStore.test.ts, and ThreadSettlementService.test.ts. vp run check:changed 2c59bf66c7fec2d3799ef62700edc2b457c15a1c also passed: format, lint, knip, graphql, affected typechecks, and 63 tests. the explicit parent ref was needed because the worker's shallow snapshot had no remote-main merge base. all 30 reported pr checks were successful.

Not verified

native desktop, ios, and android clients were not run on this linux web verification pass. successful pairing with a second environment was not exercised; only one dev server ran at a time. idle compaction and secret-request behavior were not exercised through a live provider turn. local/remote relay and tunnel connections were not exercised. the focused server tests passed, but those are not claimed as live integration proof for these paths.