[playcations]

Problem

On mobile, an open thread marks a finished run read the moment it arrives. When you resume the app on a thread, the sync can deliver a run that finished while the app was in the background before you've looked at it. If you back out right away, the thread is already marked read, so its Done marker is gone even though you never saw the result.

Repro: open a thread, background the app while its run is working, wait for the run to finish, then resume and back out as soon as the sync completes. The thread no longer shows Done.

Change

ThreadDetailScreen mounts the visit tracker through a small useSettledThreadView hook:

• Opening a synced thread in the foreground counts as viewing it at once, as today.
• Once the app leaves the foreground or the environment shell starts synchronizing, the tracker unmounts. It mounts again only after the thread has been on screen, in the foreground and not synchronizing, for two seconds. A thread opened while the shell is synchronizing waits the same way.

The rule for when a view was interrupted is a pure function in threadViewInterruption.ts. The shared visit tracker in client-runtime is unchanged, so web is unaffected.

Scope and approval

A small, focused mobile fix: a resumed or syncing thread screen was marking runs read before the user could see them. Opening a thread normally behaves exactly as before.

Verification

• vp test run apps/mobile/src/features/threads/threadViewInterruption.test.ts: 4 tests for the interruption rule: a synced open counts at once, an open during a sync waits, and a resume or sync interrupts the view until another thread opens.
• vp run check:changed: format, lint, knip, typecheck, tests, and react compiler pass. I checked the compiled hook: a new view token is created whenever the thread becomes visible again, so the wait restarts after a resume even if no timer ran in the background.
• On an Android preview build with this change, resuming on a thread whose run finished in the background and backing out right after the sync left the thread unread.

Implemented with Claude Opus 5.5 in Claude Code, through T3 Code.

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Needs Human Approval

Macroscope's review found this PR requires human approval — Resumed or synchronizing mobile threads now wait two seconds before counting as read. The changed default timing and new line-level lint suppression require human review.

^{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: 15fe283
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: 8ea99727-c1f2-4333-988c-8697c3b7922a

Commits

Reviewing files that changed from the base of the PR and between 15fe283 and 6369972.

Files selected for processing: 4

• apps/mobile/src/features/threads/ThreadDetailScreen.tsx
• apps/mobile/src/features/threads/threadViewInterruption.test.ts
• apps/mobile/src/features/threads/threadViewInterruption.ts
• apps/mobile/src/features/threads/useSettledThreadView.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

Thread visits now use a settled thread target. After an interruption, the target remains unavailable until the thread has been visible for two seconds.

Changes: Thread Visit Settling

Layer / File(s)	Summary
View interruption and settling apps/mobile/src/features/threads/threadViewInterruption.ts, apps/mobile/src/features/threads/useSettledThreadView.ts, apps/mobile/src/features/threads/threadViewInterruption.test.ts	The view state records interruptions. The hook returns an uninterrupted visible thread immediately and waits two seconds after visibility resumes following an interruption. Tests cover initial views, interruptions, thread changes, unchanged state, and null keys.
Screen visit-tracking integration apps/mobile/src/features/threads/ThreadDetailScreen.tsx	The screen passes shell synchronization status to useSettledThreadView and mounts visit tracking with the returned thread target.

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

Sequence Diagram(s)

sequenceDiagram
  participant ThreadDetailScreen
  participant useSettledThreadView
  participant AppState
  participant ThreadVisitTracker
  ThreadDetailScreen->>useSettledThreadView: Provide thread reference and shell synchronization status
  useSettledThreadView->>AppState: Check whether the app is active
  useSettledThreadView-->>ThreadDetailScreen: Return thread reference immediately or after settling
  ThreadDetailScreen->>ThreadVisitTracker: Mount with returned thread reference

Loading

Possibly related PRs

• pingdotgg/t3code#24973: Introduced the shared thread visit tracker mounted by ThreadDetailScreen.
• pingdotgg/t3code#24783: Gated the mobile thread visit watermark on active screen state.
• pingdotgg/t3code#26261: Uses thread read and completion state to drive inbox and Live Activity presentation.

Suggested reviewers: juliusmarminge

Merge Risk: Minimal · up to 63699

The changed visit behavior has no identified merge-blocking defect. The narrowed resume behavior has not yet been tested on a device.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title clearly identifies the mobile fix for runs that finish during app resume and accurately reflects the main change.
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.
Description check		The description includes complete Problem, Change, Scope and approval, and Verification sections. It explains the reproduction steps, implementation, affected scope, focused tests, broader checks, dev…

Full details: Description check

Explanation

The description includes complete Problem, Change, Scope and approval, and Verification sections. It explains the reproduction steps, implementation, affected scope, focused tests, broader checks, device verification, and agent details. The scope section does not link an issue or approval comment, but it explains why this is a small, focused bug fix, so the description is sufficiently complete.

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

No changed runtime behavior could be verified on this Linux Boat VM. I inspected the description, discussion, commits and complete diff at 6369972fbae1c6296ccdff15497819c82ba9df66. The changed path is native mobile ThreadDetailScreen → useSettledThreadView → the shared visit tracker; the web client does not execute this hook. The PR is open and GitCafe reports 31 successful checks, zero pending and zero failing. Those checks are not runtime proof.

Device discovery returned:

device_list: Agent device access is turned off for this environment.
$ timeout 20 adb devices -l
List of devices attached
[no devices]

Not verified

The original bug on main, the fix on the PR head, and neighboring mobile behavior remain unverified. Native device access is disabled and no Android device is connected. The repository mobile verification workflow requires stopping when the device tools are unavailable. I did not start a dev server, install dependencies, create app data, run a provider turn, or change code. There are no runtime screenshots or recordings to attach.

A native Android or iOS run is still required: start a real Codex gpt-6.1-sol turn, background the open thread, let it finish, resume and back out within two seconds after sync. Compare main against this head: the completion should remain unread on this head. Also verify that remaining foreground and synced for two seconds marks it read, a normal synced thread open marks it read immediately, and another background/sync interruption restarts the dwell.

[playcations]

Device verification

On a physical Pixel (Android 10), I compared two release builds from the same base: main (which already includes #28169) and main with this PR. Both ran against a throwaway server with invented projects and the dev replay provider, using a local scenario that streams for about 45 seconds and then finishes.

Steps: open a thread while it is working, background the app, wait until the run has finished (about 70 seconds), resume the app on that thread, then back out.

Build	Back out 1 s after resume	Stay about 5 s, then back out	Normal open from the list, back out after 0.5 s
main (with #28169)	Marked read
This PR	Still Done (unread)	Marked read	Marked read

One device quirk, the same on both builds: this Pixel stops presenting the app's frames after in-app navigation. I took each screenshot after a background and resume on the thread list, which doesn't change read state, and confirmed each row's state from the UI hierarchy. As a side check, the finished thread left Working on the main build, so #28169 behaves on this device too.