Windows MSIX AppData redirection prevents Godot AI MCP from reconnecting after editor restart

What version of the Codex App are you using (From “About Codex” dialog)?

26.903.9818.0

What subscription do you have?

ChatGPT Pro 20x

What platform is your computer?

• Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Possibly related to #41665.

Environment

• Codex desktop on Windows, MSIX installation
• Godot 4.7.2
• Godot AI plugin and Python server 4.0.4
• MCP connection through the pinned godot-ai attach bridge
• HTTP port 8000; editor WebSocket port 9500

Problem

Codex can reach the Godot AI MCP server, but a normally launched Godot editor cannot connect to it. Godot reports:

MCP | server start blocked: Port 8000 is occupied by another process.

The listener is an existing Godot AI backend. Calling session_manage(op="list") from Codex returns:

{"sessions": [], "count": 0, "exclude_domains": []}

Steps observed

1. Start the Godot AI MCP bridge/server through Codex desktop.
2. Open the Godot project independently with the plugin enabled.
3. Observe the port-occupied message and empty MCP session list.
4. Close Godot and launch the same project through Codex.
5. The editor adopts the existing server, authenticates, and appears as ready.
6. Launching the editor independently again reproduces the disconnected state.

Diagnostic evidence

Resolving the bridge-visible capability file with GetFinalPathNameByHandleW showed different requested and actual locations:

Requested:

%LOCALAPPDATA%\godot-ai\capabilities\http-8000.json

Actual:

%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\godot-ai\capabilities\http-8000.json

The independently launched editor could not read the corresponding connection record. The editor launched through Codex could read it and authenticated successfully without changing ports, reinstalling dependencies, or stopping the backend.

This suggests MSIX filesystem redirection separates the bridge and editor’s authentication state.

Expected behavior

The MCP bridge launched by Codex and an independently launched local editor should be able to share the intended connection state consistently across restarts, or Codex should clearly expose and document the redirected filesystem context.

Impact and workaround

Repeatedly reopening the project does not restore the connection. Launching Godot through Codex worked during testing, but is only a workaround.

No capability tokens are included in this report. The exact Codex-side implementation cause has not been isolated; the physical-path redirection and launch-dependent connection behavior were observed.

What steps can reproduce the bug?

What steps can reproduce the bug?

1. On Windows, use Codex desktop MSIX version 26.903.9818.0.
2. Configure Codex to launch a Godot AI 4.0.4 MCP bridge using godot-ai attach, with HTTP port 8000 and WebSocket port 9500.
3. Open a Godot 4.7.2 project independently of Codex, with the Godot AI plugin enabled.
4. Godot reports:

MCP | server start blocked: Port 8000 is occupied by another process.

5. Ask Codex to list connected Godot sessions:

session_manage(op="list")

Result:

{"sessions": [], "count": 0, "exclude_domains": []}

6. Close Godot and launch the same project through Codex. In our test, it adopted the existing backend and authenticated successfully, without changing ports or reinstalling anything.
7. Opening Godot independently again reproduced the disconnected state.

The following read-only Python diagnostic, run through Codex’s command tool, revealed that the connection file was redirected into Codex’s MSIX storage. It prints only the resolved path, not credentials:

import ctypes
import msvcrt
import os
from pathlib import Path

path = (
    Path(os.environ["LOCALAPPDATA"])
    / "godot-ai/capabilities/http-8000.json"
)

kernel32 = ctypes.WinDLL("kernel32", use_last_error=True)
resolve = kernel32.GetFinalPathNameByHandleW
resolve.argtypes = [
    ctypes.c_void_p,
    ctypes.c_wchar_p,
    ctypes.c_uint32,
    ctypes.c_uint32,
]
resolve.restype = ctypes.c_uint32

with path.open("rb") as file:
    buffer = ctypes.create_unicode_buffer(32768)
    length = resolve(
        msvcrt.get_osfhandle(file.fileno()),
        buffer,
        len(buffer),
        0,
    )
    if not length:
        raise ctypes.WinError(ctypes.get_last_error())
    if length >= len(buffer):
        raise RuntimeError("Resolved path exceeds buffer")
    print(buffer.value)

The requested location was:

%LOCALAPPDATA%\godot-ai\capabilities\http-8000.json

The actual opened location was:

%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\godot-ai\capabilities\http-8000.json

This suggests that the independently launched editor and Codex-launched backend see different connection records despite using the same textual path.

Codex session ID and context-window usage were not recorded. Token usage at the time of reproduction was not recorded. No authentication tokens are included.

What is the expected behavior?

What is the expected behavior?

A local MCP bridge launched by Codex and an independently launched Godot editor should consistently access the same intended connection state.

Restarting either application should allow the editor to authenticate and reconnect to the existing compatible backend without reinstalling the plugin, changing ports, or requiring Godot to be launched through Codex.

If Codex intentionally uses a separate filesystem view, that behavior should be clearly documented and a supported way to share local MCP connection state should be provided. Matching path strings should not silently refer to different files without an actionable diagnostic.

Additional information

No response

Start by reproducing the Windows MSIX launch-path difference with the godot-ai attach bridge, HTTP port 8000, WebSocket port 9500, and the godot-ai/capabilities/http-8000.json record. Compare the requested and resolved paths using the diagnostic in the issue; done means independently launched Godot and Codex-launched sessions share connection state across restarts, or the separate filesystem context has a documented supported workflow.