Skip to content

[Bug]: Opening a PDF in the macOS Browser panel repeatedly resets the whole app #21721

New issue
New issue
Closed
#21733
Closed
[Bug]: Opening a PDF in the macOS Browser panel repeatedly resets the whole app#21721
#21733
Labels
needs more infoInitial triage showed no bug. Awaiting more infovia-triageFiled through npx t3 triage

Description

@MaximilianMauroner
MaximilianMauroner
opened on Oct 19, 2026

🤖 Comment made by GPT-6 acting on behalf of @MaximilianMauroner.

Before submitting

  • I searched open and recently closed issues and did not find a report matching this full-app reset loop.
  • I included the observed steps, impact, a recording, and investigation limits.

Area

apps/desktop

Steps to reproduce

Reproduced directly through the affected macOS desktop on 19 October 2026.

  1. Open the original local project thread. Its assistant response contains an absolute file link to a generated PDF outside the registered project root.
  2. Click that file link to open it in the integrated Browser panel.
  3. The PDF panel stays blank. The whole T3 interface repeatedly clears and returns. Restart T3 Code to recover.

The opened URL is http://127.0.0.1:3773/api/assets/<redacted-token>/<file>.pdf. The asset token has kind media-file-exact. The private path and token are omitted.

Comparison tests narrow the trigger:

Test Observed result
Click the original file link in its local project thread Repeated full-app reloads. Reproduced directly.
Open an unchanged copy of the same PDF from a remote scratch thread over HTTPS PDF renders all five pages. Reproduced directly.
Paste the original local HTTP asset URL into that existing Browser tab PDF renders all five pages. Reproduced directly. Both localhost and 127.0.0.1 worked in this context.
Open a small neutral PDF in the remote scratch thread Reporter confirms that it works.

The working remote copy matches the uploaded original bytes. Fetching the original local asset URL directly returns HTTP 200, Content-Type: application/pdf, and exactly the original 48,722 bytes. A broken PDF or failed file response does not explain this result. The file-link opening workflow, thread/environment context, or preview setup remains to be traced. The local tests alone do not identify the faulty handler. The author of #21733 independently traced PDF startup recovery sending CDP Page.reload to an Electron webview guest, which reloads the embedder window. Restoring the saved PDF tab repeats that recovery. This matches the observed surviving main renderer. The proposed fix has not been installed or tested on this machine.

Expected behavior

The PDF opens, or the panel shows a clear failure with an external-open or download option. The rest of the app remains usable.

Actual behavior

Clicking the original local file link makes the thread and sidebar clear, return, and clear again. The blank PDF panel also returns. This blocks use of the app.

The sidebar briefly shows "No projects yet" during reloads. This does not establish that stored projects were deleted.

Impact

Blocks work completely.

Version or commit

0.1.1-nightly.20261019.3360, read from the installed macOS app's Info.plist.

Environment

T3 Code Nightly desktop. macOS 27.0.1, arm64. The failing link belongs to the local environment. A copy opened from a remote environment works in the same desktop app.

Logs or stack traces

The affected Mac's renderer-history.ndjson covers the original recording. Between 13:15:44 and 13:15:56 UTC, it records 16 preview creations, 16 preview destructions, and 16 main-window dom-ready events. The main renderer PID remains 61637 throughout these reloads. There is no render-process-gone event in that interval.

Selected entries with private identifiers removed:

2026-10-19T13:15:44.731Z preview webContentsId=2 dom-ready rendererPid=71069
2026-10-19T13:15:44.880Z preview webContentsId=2 destroyed rendererPid=71069
2026-10-19T13:15:44.899Z main    webContentsId=1 dom-ready rendererPid=61637
2026-10-19T13:15:45.560Z preview webContentsId=3 dom-ready rendererPid=71227
2026-10-19T13:15:45.578Z preview webContentsId=3 destroyed rendererPid=71227
2026-10-19T13:15:45.597Z main    webContentsId=1 dom-ready rendererPid=61637

This is evidence of repeated reloads with a surviving main renderer. The earlier renderer-crash recovery theory is not supported by these entries. No stack trace identifying the initiating call was captured.

Screenshots, recordings, or supporting files

t3-local-pdf-reload-redacted.mp4

New sampled desktop capture of the reproduced local file-link loop, 8.1 seconds. The sidebar, chat text, thread title, and signed asset URL are covered. It has no audio. The private PDF itself is not attached to this public issue.

Related reports and recent changes

Workaround

Restarting T3 Code restores the app after the loop starts. An unchanged copy opened from the remote diagnosis thread renders correctly. Pasting the original asset URL into an existing Browser tab also worked during testing.

Maintainer review of #21733 is the next step. This issue remains open.

Activity

  1. juliusmarminge commented on Oct 19, 2026

    @juliusmarminge
    juliusmarminge
    on Oct 19, 2026
    Member

    Note

    Grok responding on behalf of Julius.

    Thanks for the report. I couldn't find a confirmed cause in the code, so I need a few details first.

    The PDF preview change landed in nightly 3348, so the exact build matters. The desktop app also reloads the main window by itself when its renderer process dies, up to three times a minute (apps/desktop/src/window/DesktopWindow.ts:777-812). That reload would look like the app clearing and coming back with "No projects yet" for a moment. A reset of the app state without a crash would look the same, so the desktop log is what tells them apart.

    Please share:

    1. The exact T3 Code version, for example 0.1.1-nightly.20261019.3360.
    2. The desktop log from the time it happened. Look for "main window render process gone" lines and their reason.
    3. Whether a different, small PDF does the same thing.
    4. Whether the Browser tab was running in the desktop app or on the server.
  2. juliusmarminge
    added
    needs more infoInitial triage showed no bug. Awaiting more info
    via-triageFiled through npx t3 triage
    on Oct 19, 2026

  3. MaximilianMauroner commented on Oct 19, 2026

    @MaximilianMauroner
    MaximilianMauroner
    on Oct 19, 2026
    Author

    🤖 Comment made by GPT-6 acting on behalf of @MaximilianMauroner.

    @juliusmarminge, the replacement capture and the requested desktop details are now available.

    t3-local-pdf-reload-redacted.mp4
    • The installed build is 0.1.1-nightly.20261019.3360 on macOS 27.0.1, arm64.
    • Clicking the original PDF file link in its local project thread reproduces the loop. The PDF is outside the registered project root, and the opened asset uses media-file-exact.
    • An unchanged copy of that PDF renders from the remote diagnosis thread. Pasting the original local asset URL into the existing Browser tab also renders it. The small neutral PDF works too, as the reporter confirmed.
    • The local HTTP response is 200 with application/pdf and bytes identical to the source PDF.
    • The Mac renderer history shows repeated main dom-ready events and preview destruction/recreation. The main renderer keeps PID 61637, with no render-process-gone event during the original recording. The issue body now includes a short sanitized excerpt.

    The local evidence points to the file-link opening workflow or its preview setup. The author of #21733 has independently traced PDF startup recovery sending Page.reload to the guest but reloading the embedder window. The saved PDF preview then returns and repeats the cycle. That trace matches the surviving main renderer in these logs. The proposed fix is still open and has not been installed or verified here. Restarting T3 restores the app.

    This new capture covers the sidebar, private conversation, thread title, and signed URL. The private PDF has not been attached to the public issue.

  4. AurelienPautet commented on Oct 19, 2026

    @AurelienPautet
    AurelienPautet
    on Oct 19, 2026

    Additional report on T3 Code Nightly 0.1.1-nightly.20261019.3348, macOS 27.0.1, arm64.

    The affected user confirms that the UI keeps refreshing. Their recording from October 19 at 17:02:20 Europe/Paris shows the conversation repeatedly clearing and returning, Browser tabs resetting, and sidebar rows briefly overlapping. A blank local asset preview is visible. The initiating action has not yet been confirmed.

    During 15:02:20–15:02:29 UTC, renderer logs show 13 main-window dom-ready events with the same renderer PID, plus 24 preview creations and 24 destructions. There is no main render-process-gone event in that interval.

    Desktop traces also show initializeDebugger.defaultBackground failures during preview recreation. This matches the reload pattern described here; the exact cause has not been independently verified. The proposed fix in #21733 has not been tested on this installation.

    The recording below has the discussion and sidebar strongly pixelated, titles and asset URL covered, and audio removed. It preserves the repeated UI refreshes. The original recording has not been uploaded.

    t3-refresh-loop-redacted.mp4

    Investigated and posted on behalf of the affected user by GPT-6.1-Sol, Codex harness in T3 Code.

  5. Yash-Singh1
    closed this as completedin #21733on Oct 19, 2026

  6. isaac-ys-lin commented on Oct 19, 2026

    @isaac-ys-lin
    isaac-ys-lin
    on Oct 19, 2026

    Additional user report: the built-in PDF preview repeatedly opens and closes and does not settle.

    Reported behavior

    The user reports that opening a PDF from a conversation using T3 Code's built-in viewer causes continuous opening/closing. This prevents stable reading of the PDF. The conversation contains a generated PDF linked in an assistant response.

    Reported sequence:

    1. Open a PDF from the conversation in T3 Code's built-in viewer.
    2. The preview repeatedly opens and closes instead of remaining open.

    Expected: the PDF remains open for reading, and closing the preview leaves it closed.

    Environment checked on 20 October 2026

    • Installed app: T3 Code Nightly 0.1.1-nightly.20261019.3373 (read from the installed app's Info.plist).
    • macOS 26.6.2, build 25G83.
    • These are the current installed versions; the version at the precise time of the incident has not been independently established.

    Evidence and limits

    This is the affected user's observation, submitted at their request. I have not independently reproduced the loop, established whether the entire main window reloads, or determined the cause. No private conversation, PDF, local paths, signed URLs, or diagnostic logs are attached.

    This appears similar to the symptom described in this closed issue, but identity with the original defect is not confirmed. Please triage whether it is the same PDF preview loop or a separate lifecycle problem.

    Submitted by GPT-6.1-Sol through the Codex harness in T3 Code on behalf of the affected user.

  7. rryoung98 commented on Oct 20, 2026

    @rryoung98
    rryoung98
    on Oct 20, 2026

    Additional report on T3 Code Nightly 0.1.1-nightly.20261019.3373 (macOS 26.6, arm64, desktop app). Build 3373 is still affected, although this issue is closed.

    The user confirms the trigger: opening a PDF in the desktop Browser panel started the loop. Force-quitting and relaunching restores the same thread and Browser tab, and the loop resumes right away.

    Evidence from local logs:

    • Two sessions (18:10 and 18:57 local) show the same cycle every ~0.8s: the preview webview is created, hits dom-ready and is destroyed, then the main window fires dom-ready again. That happened 31 times in total.
    • The main renderer PID stays the same, and there is no render-process-gone event. The window is reloading, not crashing.
    • Each cycle logs a PreviewManager.initializeControlSession failure, initializeDebugger.defaultBackground, about 100ms after registerWebview, followed by recoverDetachedControlSession. The 18:10 session ended with a registerWebview.restoreZoomFactor failure.

    This matches the diagnosis in #21733: Page.reload sent through the webview's debugger reloads the embedder window. #21733 merged at 20:28 UTC on Oct 19, after 3373 was cut, and 3373's GuestInput.ts has no Page.reload guard. A nightly that includes 284ce8fe should fix it.

    Workaround (confirmed by the user): while the loop runs, open DevTools (Cmd+Option+I), run localStorage.removeItem("t3code:right-panel-state:v2") in the console, then quit and relaunch. The restored PDF tab no longer reopens, and the app is usable again. This resets which right panels are open per thread; threads and messages are unaffected.

    Investigated with Claude Opus 5.5 in Claude Code via t3 triage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    needs more infoInitial triage showed no bug. Awaiting more infovia-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions