You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: Closing an expanded image with the top-right X quits the whole app and kills all running agents #12930
I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.
Area
apps/desktop
Steps to reproduce
Windows desktop app.
Start one or more agents in the desktop app and leave them running.
Open a thread that contains an image and click the image to open it in the expanded viewer.
Finish looking at the image and click the X in the top right corner of the window, which is the biggest and most obvious close control on screen.
Expected behavior
The expanded image viewer should have its own clearly visible close control, and clicking it should close only the viewer and bring me back to the chat, with every running agent untouched.
Separately, quitting the app while agents are running should ask for confirmation first, something like "Quit T3 Code and stop all running agents?", so that a single misclick cannot throw away work in progress.
Related: #10697 asks for a confirmation prompt before closing the window while agent tasks are running, which would also soften this case.
Actual behavior
While the image is expanded, the only obvious X on screen is the window close button in the top right corner. Clicking it quits the entire app instantly, with no confirmation, and every running agent is interrupted. Work in progress is lost and the agents have to be started over.
Esc does close the viewer, but it is not discoverable, and reaching for it is awkward when there is a big visible X sitting right there.
Impact
Major degradation or frequent failure
Version or commit
latest stable release
Environment
Windows, T3 Code desktop app, latest stable release
Logs or stack traces
Screenshots, recordings, or supporting files
No response
Workaround
Press Esc to close the viewer instead of clicking the X. It works, but it is not obvious, and the visible X stays a trap.
Thanks for the report. This is a real Windows desktop bug, and it is not a duplicate of the quit-confirmation request.
What happens
The expanded viewer does have its own close button, but it is easy to miss and, for a large image, it sits in the same corner as the window Close button.
ExpandedImageDialog turns off the dialog’s normal close button and draws a 24px X (icon-xs, media-close) at absolute right-0 -top-10 — 40px above the image, on the dark backdrop. On Windows and Linux the desktop window is frameless with a 40px native caption overlay (titleBarStyle: "hidden", titleBarOverlay.height 40 in DesktopWindow). That overlay is painted above the page, and its right side is Minimize / Maximize / Close. A wide, tall image puts the viewer’s X in or just under that strip, so the obvious control is the window Close button.
Clicking it does not ask. The window close handler only saves bounds. On non-macOS, window-all-closed quits the app, and quit stops every backend in the pool, which aborts running agents. Settings → General → Quit shortcut (confirmQuit) only intercepts Ctrl/Cmd+Q. It does not cover the title-bar X.
Escape is handled inside the dialog and closes only the viewer, which matches what you found. On macOS, closing the window does not quit the app, so this trap is the Windows/Linux caption overlay.
No open PR moves this close button out of the caption strip.
Next step
Place a visible viewer close control in the page area to the left of the window-controls overlay (the app already knows that rectangle via the wco class and titlebar-area-*), clear of the top 40px caption band. The quit-confirmation decision can stay on #10697.
Activity
juliusmarminge commentedon Sep 21, 2026
Thanks for the report. This is a real Windows desktop bug, and it is not a duplicate of the quit-confirmation request.
What happens
The expanded viewer does have its own close button, but it is easy to miss and, for a large image, it sits in the same corner as the window Close button.
ExpandedImageDialogturns off the dialog’s normal close button and draws a 24pxX(icon-xs,media-close) atabsolute right-0 -top-10— 40px above the image, on the dark backdrop. On Windows and Linux the desktop window is frameless with a 40px native caption overlay (titleBarStyle: "hidden",titleBarOverlay.height40 inDesktopWindow). That overlay is painted above the page, and its right side is Minimize / Maximize / Close. A wide, tall image puts the viewer’sXin or just under that strip, so the obvious control is the window Close button.Clicking it does not ask. The window
closehandler only saves bounds. On non-macOS,window-all-closedquits the app, and quit stops every backend in the pool, which aborts running agents. Settings → General → Quit shortcut (confirmQuit) only intercepts Ctrl/Cmd+Q. It does not cover the title-bar X.Escape is handled inside the dialog and closes only the viewer, which matches what you found. On macOS, closing the window does not quit the app, so this trap is the Windows/Linux caption overlay.
Not the same issue
No open PR moves this close button out of the caption strip.
Next step
Place a visible viewer close control in the page area to the left of the window-controls overlay (the app already knows that rectangle via the
wcoclass andtitlebar-area-*), clear of the top 40px caption band. The quit-confirmation decision can stay on #10697.fix(web): image viewer lays out below the window controls
fix(web): image viewer lays out below the window controls
fix(web): image viewer lays out below the window controls
fix(web): image viewer lays out below the window controls
fix(web): image viewer lays out below the window controls