Multiple app-server instances sharing CODEX_HOME cause IPC router re-election loop and WAL unbounded growth

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

26.820.71523 (desktop app bundled codex.exe: 0.150.0-alpha.8)

What subscription do you have?

free

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

When both the ChatGPT desktop app and VS Code extension are running simultaneously, they spawn separate codex.exe app-server processes that share the same CODEX_HOME directory (C:\Users\<user>\.codex). This causes:

1. IPC router re-election loop: The IpcRouter repeatedly re-elects itself (6 times in 80 seconds in my logs), and
   broadcasts are dropped with "Received broadcast but no handler is configured"
2. SQLite WAL unbounded growth: logs_2.sqlite-wal grows to 415 MB despite wal_autocheckpoint = 1000 (~4 MB
   threshold), because concurrent writers prevent checkpoint from ever succeeding
3. UI becomes unresponsive: Clicks in the UI have no effect (though the process reports Responding = True)

Evidence

Two app-server instances with shared CODEX_HOME:

PID 5320 (VS Code ext) Parent: Code.exe
c:\Users.vscode\extensions\openai.chatgpt-26.820.71523-win32-x64\bin\windows-x86_64\codex.exe
-c features.code_mode_host=true app-server --analytics-default-enabled

PID 31384 (Desktop app) Parent: ChatGPT.exe
C:\Users.codex\bin\codex.exe
-c features.code_mode_host=true app-server --analytics-default-enabled

Both point to the same CODEX_HOME: C:\Users\<user>\.codex

IPC router re-election (from VS Code extension log):

2026-08-27 15:08:54.725 [warning] [IpcClient] Received broadcast but no handler is configured
method=ipc-connection-reset
2026-08-27 15:08:55.735 [info] [IpcRouter] I am the router
2026-08-27 15:14:27.107 [info] [IpcRouter] I am the router
2026-08-27 15:14:34.811 [info] [IpcRouter] I am the router
2026-08-27 15:15:00.037 [info] [IpcRouter] I am the router
2026-08-27 15:15:06.407 [info] [IpcRouter] I am the router
2026-08-27 15:15:36.956 [info] [IpcRouter] I am the router
2026-08-27 15:15:45.194 [info] [IpcRouter] I am the router

WAL checkpoint failure (read-only query via Python sqlite3):

journal_mode: ('wal',)
page_size: (4096,)
wal_autocheckpoint: (1000,) ← should checkpoint every ~4 MB
page_count: (10,)

logs_2.sqlite: 40,960 bytes (10 pages)
logs_2.sqlite-wal: 415,102,392 bytes ← 100x over threshold

logs table row count: 0 ← nothing ever checkpointed into main DB

File sizes over time (no checkpoint activity):

2026-08-27 15:15:39 415102392 logs_2.sqlite-wal
2026-08-27 15:15:39 40960 logs_2.sqlite
--- wait 8 seconds ---
2026-08-27 15:15:39 415102392 logs_2.sqlite-wal ← frozen, no growth or shrinkage
2026-08-27 15:15:39 40960 logs_2.sqlite

What steps can reproduce the bug?

1. Open the ChatGPT desktop app (Windows version from Microsoft Store or standalone installer)
2. Open VS Code with the openai.chatgpt extension installed
3. Verify both are using the same CODEX_HOME:
   • Desktop app uses C:\Users\<user>\.codex\bin\codex.exe
   • VS Code ext uses <ext-dir>\bin\windows-x86_64\codex.exe
   • Both write to C:\Users\<user>\.codex
4. Use the desktop app for 10+ minutes (issue session, run tools, etc.)
5. Check task manager: two codex.exe processes are running
6. Check ~/.codex/logs_2.sqlite-wal size: grows indefinitely
7. Click in the UI: no response (though process shows Responding = True)

The issue occurs consistently when both apps are open. Closing one app resolves it.

Note: I am running 0.150.0-alpha.8 (desktop app bundled binary) with a custom model_provider.base_url in
config.toml. However, the root cause appears to be architectural (concurrent app-server instances sharing state),
not configuration-specific. I have not yet reproduced this on a clean official setup, but can do so if needed.

What is the expected behavior?

One of the following:

1. Singleton enforcement: Only one app-server instance should be allowed per CODEX_HOME, with a lock file
   preventing the second instance from starting (similar to how browsers handle profile directories)

2. Separate CODEX_HOME per launcher: The VS Code extension and desktop app should use isolated state directories
   (e.g., ~/.codex-vscode/ vs ~/.codex/)

3. Shared-state safety: If concurrent instances are intentional, the IPC and SQLite layers should handle
   concurrent access gracefully (e.g., one writer + multiple readers, proper WAL checkpoint coordination)

Current behavior (silent conflict + unbounded WAL growth + UI freeze) should not occur.

Additional information

• This happened before: I have three directories under Documents/codex/2026-06-28/ named
  codex-logs-2-sqlite-trace, -2, -3, suggesting I investigated the same WAL issue in late June

  • The prior sqlite/logs_2.sqlite from June 17 was 115 MB, same pattern
  • C: drive has 34 GB free
  • The .codex/bin/codex.exe binary is 307 MB
  • Orphan temp file exists: ..codex-global-state.json.tmp-1787812249641-... from Aug 27 14:30, suggesting an
    interrupted atomic write

  Workaround: Close one of the two apps (either ChatGPT desktop or VS Code) before using the other.

  If useful, I can provide:

  • Full Codex.log from VS Code extension (with tokens redacted)
  • Output of sqlite3 logs_2.sqlite "pragma integrity_check; pragma wal_checkpoint(TRUNCATE);"
  • Strace/procmon capture showing the lock contention

Start with the app-server's IpcRouter behavior and SQLite handling for logs_2.sqlite, then reproduce the two-process Windows setup described in the issue. Trace the repeated router elections, WAL checkpoint behavior, and UI freeze. Done should prevent the conflict from causing unbounded WAL growth and an unresponsive UI, with tests or reproduction evidence for the chosen isolation or coordination approach.