Activity

1. juliusmarminge commented on Oct 12, 2026

   

   juliusmarminge

   on Oct 12, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   This needs a reproduction before we can act on it. On main, nothing traps you in an MCP App full screen. Full screen only opens when the app itself asks for it (ui/request-display-mode). The modal always has an X / Exit full screen button that pops back to the thread. If the app fails to load, it shows "Unable to load the blender app" instead of retrying. The "connecting/reconnecting" text is most likely drawn by the Blender viewport inside its frame while it waits for a Blender instance that isn't running. If it's the client's connection banner instead, this is probably #15365.

   Could you send:

   1. The client (iOS/desktop/web) and its build number?
   2. A screenshot or recording of the loop. Is the X in the top-right visible, and does tapping it do nothing?
   3. Does it happen with Blender (the MCP server) closed vs. running?

   If we don't hear back within 14 days, this will auto-close.
2. juliusmarminge

   added

   needs more infoInitial triage showed no bug. Awaiting more infoInitial triage showed no bug. Awaiting more info

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 12, 2026
3. robicity commented on Oct 12, 2026

   

   robicity

   on Oct 12, 2026

   Author

   More actions

   Follow-up to the reproduction questions, tested on 2026-10-12:

   Client/build: Windows desktop 0.0.46-nightly.20261011.2994, verified from the running installation's executable version. The iOS behavior remains user-reported; its build has not been recorded.

   The Exit button is present, but overlaps the native window Close button. In the Windows app, the Blender fullscreen header starts at the very top of the window. Its rightmost Exit full screen icon occupies the same area as the native T3 window's X. The minimize/fullscreen icon and X are visibly superimposed. This occurs both in a maximized window and in a smaller window. An attempt to click the accessibility-labelled Exit full screen control was followed by the T3 window becoming unusable; the desktop app had closed and the user restarted it to continue this diagnostic thread. I cannot independently attribute which overlapping hit target received that click, but the visual overlap is directly captured.

   Blender closed versus running: With Blender closed, opening the existing thread and bringing its stored blender.look row into view automatically opened the Blender viewport full screen, without an explicit request from the user to expand it. The stored image showed a broken-image placeholder.

   After opening Blender 5.2.2 LTS, the add-on panel showed Running on port 9876. The actual listening socket is on 127.0.0.1:9876, and the configured MCP executable uses the same default port. Direct get_addon_status and get_scene_info calls succeeded against that Blender instance. Reopening the stored viewport still automatically opened full screen. Refresh displayed:

   Couldn't reach Blender: The app's MCP server request failed.
   

   The viewport remained stuck with the broken image after Refresh. The same visible failure occurred in another existing Blender thread opened during the test. No Confirm/Cancel recovery dialog appeared in this controlled attempt. This does not identify why the embedded app's request fails while direct MCP calls succeed.

   Clarification of the original report: The user reports that X can be pressed, but the same window appears again. This is a close/reopen loop, rather than a claim that the X never reacts. I have independently verified Windows fullscreen entry, blocked navigation, the overlapping Close/Exit controls and the failed Refresh with Blender running. I have not completed an independent series of close/reopen cycles, because the overlapping control shut down T3 during the first exit attempt. I have not reproduced the iOS client behavior.

   Static investigation lead: The installed Blender viewport declares only fullscreen and calls goFullscreen() immediately after ui/initialize. In current T3 mobile source, returning from fullscreen reloads the inline app document (McpAppWebView.tsx, lines 203-215). That new document can request fullscreen again. This is a plausible mobile close/reopen mechanism, not a confirmed runtime trace:

   t3code/apps/mobile/src/features/threads/McpAppWebView.tsx

   Lines 203 to 215 in 48595c7

   	// Back from full screen: the thread shows a fresh inline view of the app.
   	// The listener reads the latest helper, whose URL comes from this render.
   	const openNewDocument = useRef(setDocumentKey);
   	useEffect(() => {
   	openNewDocument.current = setDocumentKey;
   	});
   	useEffect(() => {
   	if (!presentedFullscreen) return;
   	return navigation.addListener("focus", () => {
   	openNewDocument.current((value) => value + 1);
   	setPresentedFullscreen(false);
   	});
   	}, [navigation, presentedFullscreen]);

   Screenshots were captured successfully. The attempted window video contained black frames and is not usable evidence. The screenshots can document the Windows overlap and Refresh error; no private conversation contents or signed asset URLs are included in this comment.
4. robicity commented on Oct 12, 2026

   

   robicity

   on Oct 12, 2026

   Author

   More actions

   Adding the requested screenshot evidence.

   The user confirms iOS TestFlight version 2.0.0; the exact TestFlight build number is still unknown. The two iOS screenshots show the Blender fullscreen view, a visible X, a broken viewport image, and then the explicit error: Couldn't reach Blender: The app's MCP server request failed.

   These are still images, so they do not independently demonstrate the repeated reopening. The user reports that pressing X closes the view but the same fullscreen view immediately opens again.

   The third screenshot is from the Windows desktop test described above. It shows the Refresh error and the fullscreen-exit icon overlapping the native window X.

   
5. trentwadams commented on Oct 13, 2026

   

   trentwadams

   on Oct 13, 2026

   More actions

   Follow-up confirming the same behaviour on a second setup, tested on 2026-10-13:

   Same symptoms on iOS and Windows desktop. On iOS, the Blender viewport opens full screen with the X visible. Pressing X closes it, but the same full-screen view opens again straight away. On the Windows desktop app, the Blender full-screen header's Exit full screen icon sits underneath the native window X, the same overlap shown in the screenshot above. Pressing 'esc' or any other key does not close the preview window.

   Setup differs from the original report: the backend is a Mac, reached remotely. T3 Code and the agents run on a Mac. I use them from a Windows PC: the Windows T3 desktop app connects to the Mac over Tailscale HTTPS (tailscale serve, tailnet-only). So the overlap happens even when the Windows client is only displaying a remote Mac environment. The Blender MCP server and the Blender instance are both local to the Mac. The agent driving Blender is a Codex thread.

   Versions (Mac host):

   • macOS 15.7.9 (24G830), Intel x86_64
   • T3 Code (Nightly) 0.0.46-nightly.20261013.3042
   • Codex CLI 0.162.1 (Homebrew cask), Codex.app 26.305.950
   • Claude Code 2.1.296
   • Node v25.8.2
   • Blender 4.5.13 LTS, add-on blender_mcp.py v1.8, listening on 127.0.0.1:9876
   • blender-mcp 2.0.0, launched via uvx blender-mcp from the Codex MCP config
   • Tailscale 1.98.5

   Clients:

   • Windows T3 desktop: 0.0.46-nightly.20261013.3042
   • iOS: 2.0.0 (122)

   Blender state: Blender was running, with the add-on listening on 9876 while this happened, so this isn't the Blender-closed case.

   This matches the other report: the Exit control overlaps the native Close button on desktop, and the full-screen view reopens after closing on iOS. My setup adds a remote macOS backend over Tailscale, which suggests the problem is in the client and not tied to where the backend runs.
6. juliusmarminge

   closed this as completedin #18548on Oct 19, 2026