Sign up
View stargazersSign up

Android file viewer keeps stale content until the app is closed and reopened#29345

opened10d agobyMmayesidev

What happened

T3 mobile app 2.2.0 on Android 17 showed the original contents of a workspace Markdown file after the agent revised it on the host. Stale content appeared through both a normal chat file link and the Files browser. Closing T3 normally from Android's app switcher and reopening it finally showed the current contents.

Expected: A workspace file viewer should reflect host edits, or expose a working refresh action. Reopening a file from a refreshed folder should not silently show obsolete contents.

Diagnosis

The host file was confirmed current. Uppercase and lowercase spellings of AGENTS.md resolve to the same file on the host, so this was not two different host files. A controlled probe reproduced the stale-content behavior without changing AGENTS.md further.

In the inspected local source, both entry points use the shared workspace readFile query. That query has a 30-second stale window and five-minute idle retention, with no file-change refresh signal or refresh interval configured. The local query implementation revalidates on mount. These are candidate cache/revalidation boundaries, not a confirmed root cause. A rendered-content cache or another client layer has not been ruled out.

The local checkout is not established as the exact shipped mobile 2.2.0 build. Although it contains a Markdown RefreshControl, the user could not pull to refresh inside a file on the affected app. Folder refresh is a separate operation and did not resolve the stale file.

Steps to reproduce

  1. In the Android T3 app, open a workspace Markdown probe displaying Revision A.
  2. Keep T3 foregrounded while an agent changes that same host file to Revision B.
  3. Inspect the file; it still shows Revision A.
  4. Return to the folder view, pull to refresh the folder, and reopen the probe from the folder instead of the chat link; it still shows A.
  5. Switch apps, navigate home and back, leave/re-enter the thread, and switch threads, refreshing between attempts; it still shows A.
  6. Close T3 normally from Android's app switcher, then reopen it and inspect the same probe; it now shows B.

The host server was not restarted. No app data was cleared, and Android Force stop was not used.

Version

T3 mobile app 2.2.0; connected host server 0.1.6

Environment

Affected client: T3 mobile app 2.2.0 on Android 17. Phone: Pixel 10 XL. App distribution channel: not yet provided. Connected host: macOS arm64, T3 server 0.1.6, desktop Beta installation. Source inspected: existing local checkout 7d9725abf4; not proven to match the shipped mobile app.

Evidence

The agent verified the probe contained Revision B on disk while the user saw A on the phone. The user confirmed B only after closing and reopening T3. Relevant source leads: packages/client-runtime/src/state/projectCommands.ts; state/runtime.ts; apps/mobile/src/features/files/ThreadFilesRouteScreen.tsx; FileMarkdownPreview.tsx. Recent host trace included successful file-read requests but did not identify successful request paths or response bodies, so it cannot establish what the client received for this probe.

https://github.com/pingdotgg/t3code/issues/5779 — closed desktop stale-content report; similar symptom, not a confirmed duplicate. https://github.com/pingdotgg/t3code/issues/6452 — closed directory-list freshness report; this report concerns file contents.

Fix applied or workaround

Close the mobile app from Android's app switcher and reopen it. Folder refresh and navigation did not work. Force stop was not tested.

Filed by

Codex, gpt-6.1-sol; T3 triage playbook followed in existing session.

Both pull requests are currently open.