[Windows][WSL][26.730.8199.0] Integrated terminal silently fails before PTY/WSL startup; bottom and side panel cannot open

Resolved 💬 22 comments Opened Aug 5, 2026 by cxzhong Closed Aug 26, 2026

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using?

Codex Desktop from the Microsoft Store:

Package: OpenAI.Codex_26.730.8199.0_x64__2p2nqsd0c76g0
App package version: 26.730.8199.0

What subscription do you have?

Not disclosed; the failure appears entirely local to the Desktop renderer/terminal lifecycle.

What platform is your computer?

Windows 11 Enterprise x64
OS version: 10.0.26200.8973
WSL2
Distribution detected by Codex: Ubuntu 26.04

What issue are you seeing?

The integrated terminal cannot be opened in Codex Desktop when the agent environment and integrated shell are configured for WSL.

All available entry points fail:

View → Open Terminal
Ctrl+`
Toggle bottom panel
Bottom-panel “open tab” menu → Terminal
Side-panel “open tab” menu → Terminal

Depending on the entry point, the panel either does nothing or flashes briefly and immediately disappears. No usable terminal tab remains visible.

The same failure reproduces in:

a projectless local task; and
an existing folder-backed local task whose workspace is under /home/<user>/... in WSL.

This is not a shell startup failure after the terminal UI opens. The terminal backend is never reached.

Desktop configuration

[desktop]
runCodexInWindowsSubsystemForLinux = true
integratedTerminalShell = "wsl"

The shipped settings schema for this build accepts wsl as a valid integrated-terminal shell.

Steps to reproduce

Install/open Codex Desktop 26.730.8199.0 on Windows 11 with WSL2.
Set Agent environment to Windows Subsystem for Linux.
Set Integrated terminal shell to WSL.
Open an existing local folder-backed task in a WSL project.
Select View → Open Terminal or press Ctrl+`.
Alternatively, open the bottom- or side-panel tab picker and choose Terminal.
Observe that no terminal remains open. The panel may flash and immediately close.

Expected behavior

The selected panel should remain open and either:

attach a terminal session in the active task/workspace; or
display a visible, actionable terminal error.

It should never silently no-op or auto-collapse.

Actual behavior

No usable terminal tab is created.
No WSL terminal process is spawned for the action.
No PTY module is loaded.
No terminal-specific error is shown to the user.
The action silently returns or the panel flashes closed.

Diagnostic evidence

1. WSL itself is healthy

From Windows, wsl.exe --status succeeds and a direct command such as:

wsl.exe -e /bin/sh -lc "pwd; printf terminal-ok"

runs successfully from the same workspace context.

Codex also launches its app-server and normal task commands inside WSL successfully. The failure is isolated to the integrated-terminal UI path.

2. Terminal action never reaches the PTY backend

While invoking the terminal through the menu and keyboard shortcut, process/module monitoring showed:

no new wsl.exe process attributable to the terminal action;
no pty.node, conpty.node, or winpty module loaded by any Codex/ChatGPT process;
the packaged node-pty and ConPTY assets are present on disk;
no Microsoft Defender block or quarantine event.

The app log contains no terminal/PTY creation error around the action. This is consistent with a renderer guard returning before terminal creation.

3. The shipped renderer contains a route/thread-ID mismatch

Inspection of the shipped Desktop renderer bundle shows that the route parser produces an existing local-thread route containing conversationId:

{
  routeKind: "local-thread",
  conversationId,
  hostId,
  projectContext,
  ...
}

However, the integrated-terminal target resolver uses clientThreadId for that route and returns null for a client-local route. Equivalent pseudocode:

function resolveTerminalTarget(scope) {
  switch (scope.value.routeKind) {
    case "home":
      return target(scope.value.clientThreadId);

    case "local-thread":
      return {
        conversationId: scope.value.clientThreadId, // undefined on this route
        conversationTitle: getTitle(scope.value.conversationId),
        cwd: getCwd(),
        hostId: getHostId(),
      };

    case "client-local-thread":
      return null;

    default:
      return null;
  }
}

For an existing local-thread, the terminal target therefore receives an undefined conversation ID.

The terminal wrapper then treats a null/undefined conversation ID as having no conversation snapshot and returns without rendering the actual TerminalPanel. As a result, the effect that calls the terminal host service never runs, which explains all observed evidence:

no terminal tab/content;
no PTY load;
no wsl.exe spawn;
no backend error.

4. The global terminal-command fallback also lacks route scope

The global toggleTerminal fallback invokes the windows.terminal.toggle app action without an action context:

toggleTerminal = () => {
  runAppAction({
    type: "windows.terminal.toggle",
    windowId: "current",
  });
};

But the registered action requires a route scope before calling the terminal toggle:

run: (_action, context) => {
  toggleTerminal(requireRouteScope(context));
}

The fallback does not await or handle the rejected promise. When the route-specific handler is inactive, View → Open Terminal / the shortcut therefore becomes a silent no-op instead of surfacing “App action requires a route scope”.

Why this appears to be a Desktop routing/session-ownership regression

The public issue history already contains the same user-visible failure and a closely matching thread-owner analysis:

#26950 — Windows terminal flashes and immediately closes
#25256 — Windows bottom panel flashes and disappears
#29090 — bottom and side terminal panel fail similarly
#31417 — terminal snapshot lookup misses sessions because temporary/permanent thread ownership IDs diverge
#28141, especially issue comment 4953033965 — shipped-renderer analysis of client-local-thread returning null and terminal sessions being indexed by clientThreadId

A user reported that the macOS behavior in #28141 was fixed in Desktop 26.721.41059. However, Windows package 26.730.8199.0 still reproduces the failure, and its shipped renderer still contains the problematic resolver/fallback control flow. This may be a Windows packaging gap or a regression/reintroduction.

Suggested fix

Return a valid terminal target for both local-thread and client-local-thread.
Resolve the correct canonical/aliased client thread ID instead of reading a field that is absent from the local route.
Use the same alias-aware conversation key for:

terminal session storage;
terminal panel rendering;
terminal snapshot/read lookup.

Pass the active route scope to the global windows.terminal.toggle action, or route the command through the mounted route-specific handler.
Await/log failures from terminal toggle actions.
Keep the panel visible with a loading or error state if terminal attachment fails.

Regression coverage

Existing folder-backed local thread: terminal opens and accepts input.
Projectless local thread: terminal opens and accepts input.
client-local-thread → permanent local-thread materialization: the same terminal session remains attached.
View menu, keyboard shortcut, bottom-panel picker, and side-panel picker all reach the same working terminal action.
Forced PTY failure: panel stays visible with an actionable error.
Windows + WSL: opening the terminal results in an observable PTY/WSL process and a registered terminal session.

Additional information

No private task IDs, user paths, or raw logs are included here. A sanitized log excerpt or feedback/session ID can be supplied if maintainers request it.

View original on GitHub ↗

22 Comments

github-actions[bot] contributor · 22 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#36794

Powered by Codex Action

cxzhong · 22 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate. * [[macOS] Toggle Bottom Panel (⌘J) does nothing in Codex #36794](https://github.com/openai/codex/issues/36794) _Powered by Codex Action_

Not, This is Windows Case

StreamVi · 22 days ago

Additional confirmation after explicitly changing the integrated terminal shell to WSL and fully restarting Codex Desktop.

Environment:

Windows 11 build 10.0.26200.8973
Codex Desktop MSIX: OpenAI.Codex_26.730.8199.0_x64__2p2nqsd0c76g0
WSL2 distro: Ubuntu-22.04
WSL Codex CLI: codex-cli 0.146.0

Effective configuration after restart:

[desktop]
runCodexInWindowsSubsystemForLinux = true
integratedTerminalShell = "wsl"

The result is unchanged: opening the terminal/bottom panel briefly shows the panel and it immediately closes. The same symptom previously reproduced with integratedTerminalShell = "powershell", so the selected terminal shell is not the trigger.

Fresh startup diagnostics show that the WSL agent path itself is healthy:

Desktop detects Ubuntu-22.04.
Desktop spawns the app-server through wsl.exe.
The app-server reaches the connected/initialized state.
A direct Windows-to-WSL command succeeds in the same repository.
Inside WSL, codex --version and git status both succeed.

After attempting to open the integrated terminal, persisted UI state for the active task still contains no terminal route or session:

{
  "routes": [],
  "topology": {
    "bottom": {
      "activeTabId": null,
      "open": false,
      "tabIds": []
    }
  }
}

The fresh Desktop log contains only successful thread/backgroundTerminals/clean requests for this task. There is no terminal-create request, PTY startup, WSL terminal spawn, or terminal-specific backend error around the action. This supports the renderer/route early-return diagnosis in this issue: the UI collapses before the terminal host is reached.

Two additional startup warnings remain on this build:

bundled_executable_relocation_failed ... executableName=bwrap ... errorCode=ENOENT
Failed to apply worktree shell environment config ... errorMessage="Git is unavailable"

However, /usr/bin/bwrap is installed and functional in WSL, Codex's previously relocated codex-resources/bwrap is also present and executable, and Git works normally inside WSL. These warnings appear to be separate Windows/WSL packaging and Git-worker regressions rather than an explanation for the terminal action never reaching PTY creation.

Changing the shell, repairing/resetting local startup state, updating the WSL CLI, and restarting Desktop do not resolve the terminal failure. A fix appears to require the Desktop renderer/session-routing changes described in the issue body.

matthewclso · 22 days ago

On Codex Desktop 26.730.8199.0, I found two stacked failures in the Windows/WSL integrated-terminal path. First, the renderer loses terminal ownership when a temporary client thread becomes a persisted local thread. After correcting that lookup, terminal creation reaches the main process but still aborts before node-pty starts because an optional Git/worktree-environment lookup throws Git is unavailable. That fatal host error removes the terminal snapshot, so the renderer immediately closes the tab and panel—the brief flash users see.

How I isolated it

Confirmed that wsl.exe, Windows Git, WSL /usr/bin/git, and a direct shell in the same repository all work.
Traced the shipped app through a version/hash-gated preload; the signed MSIX and app.asar remained unchanged.
The trace showed a valid terminal target and session, followed by host-event type=error message="Git is unavailable"; no PTY had spawned.
The exception comes from the optional getWorktreeRepository(...) callback used while building the terminal environment. Terminal creation treats that callback failure as fatal, removes the session snapshot, and the UI reconciler closes the panel.

The important main-process fallback is:

async cwd => {
  try {
    const repo = await gitManager.getWorktreeRepository(normalize(cwd), host);
    return repo == null ? null : toShellEnvironment(repo);
  } catch {
    return null; // continue with the ordinary terminal environment
  }
}

The complete workaround also applies the renderer route/thread-alias fixes described in the issue body and normalizes a bare wsl.exe launch whose CWD is a WSL UNC path.

Temporary workaround for other users

This is an unofficial workaround for the Microsoft Store build 26.730.8199.0 only. It does not modify the installed package. Review the script before using it.

Fully quit Codex from the tray. A running process will not inherit the shim.
In PowerShell, download the terminal-only preload shim and verify the pinned file:

$fixDir = Join-Path $env:USERPROFILE '.codex-wsl-launcher'
$shim = Join-Path $fixDir 'CodexTerminalRouteShim.cjs'
New-Item -ItemType Directory -Path $fixDir -Force | Out-Null

$url = 'https://gist.githubusercontent.com/matthewclso/5353141038cd9212d2634f8d34f2d150/raw/cb95ed3e79f06863f93c31a1bb8ebcad70fed038/CodexTerminalRouteShim.cjs'
Invoke-WebRequest -UseBasicParsing $url -OutFile $shim

$expected = '68B1457D7ACF5CE7C443C022D50956285E77AA13F33D9437E3C0C80148AAB4BF'
if ((Get-FileHash $shim -Algorithm SHA256).Hash -ne $expected) {
    throw 'Downloaded shim hash does not match the tested file.'
}

Save the following as Start-Codex-Terminal-Fix.ps1 in that same directory:

<details>
<summary>PowerShell launcher</summary>

$ErrorActionPreference = 'Stop'
$fixDir = Join-Path $env:USERPROFILE '.codex-wsl-launcher'
$shim = Join-Path $fixDir 'CodexTerminalRouteShim.cjs'
$log = Join-Path $fixDir 'terminal-route-shim.log'

$package = Get-AppxPackage -Name 'OpenAI.Codex' |
    Sort-Object Version -Descending | Select-Object -First 1
if ($null -eq $package) { throw 'OpenAI.Codex is not installed.' }
if ($package.Version.ToString() -ne '26.730.8199.0') {
    throw "This shim was tested only with Codex 26.730.8199.0; installed: $($package.Version)"
}
if (-not (Test-Path -LiteralPath $shim -PathType Leaf)) {
    throw "Shim not found: $shim"
}
if (Get-Process -Name ChatGPT -ErrorAction SilentlyContinue) {
    throw 'Codex is already running. Fully quit it from the tray first.'
}

$previous = [Environment]::GetEnvironmentVariable('NODE_OPTIONS', 'Process')
$requireOption = "--require=`"$shim`""
if ($null -eq $previous) {
    $env:CODEX_TERMINAL_ROUTE_SHIM_ORIGINAL_NODE_OPTIONS = '__CODEX_NODE_OPTIONS_UNSET__'
    $env:NODE_OPTIONS = $requireOption
} else {
    $env:CODEX_TERMINAL_ROUTE_SHIM_ORIGINAL_NODE_OPTIONS = $previous
    $env:NODE_OPTIONS = "$requireOption $previous"
}
$env:CODEX_TERMINAL_ROUTE_SHIM_ENABLED = '1'
$env:CODEX_TERMINAL_ROUTE_SHIM_LOG = $log

$exe = Join-Path $package.InstallLocation 'app\ChatGPT.exe'
Start-Process -FilePath $exe -WorkingDirectory (Split-Path -Parent $exe)

</details>

Launch that script directly, or create a shortcut whose target is:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -ExecutionPolicy Bypass -File "C:\Users\<you>\.codex-wsl-launcher\Start-Codex-Terminal-Fix.ps1"

Open the integrated terminal. The local terminal-route-shim.log should contain main_module_patched, renderer_patched, terminal_pty_spawn, a host event with "type":"attached", and terminal_pty_first_output.

With the workaround, I successfully opened two WSL terminals. Before it, every attempt ended with Git is unavailable before PTY creation.

To remove it, fully quit Codex and launch the normal Start-menu shortcut instead. No reinstall or package repair is needed. After any Codex update, stop using this launcher and test the stock app first; the launcher rejects other versions and the shim also checks the exact bundled-file hashes. The diagnostic log can contain local paths, so redact it before sharing.

For the product fix, worktree-shell-environment lookup should be best-effort, the renderer should use alias-aware terminal ownership consistently, and terminal-host failures should remain visible instead of collapsing the panel.

Arthur-Artoria · 20 days ago

Still reproducible in Windows package 26.803.5235.0.

Environment:

Windows 11 10.0.26200
WSL 2.6.3
Ubuntu 24.04
/bin/bash and PTY work
System bubblewrap 0.9.0 installed
New WSL folder-backed chats work normally
Integrated terminal panel flashes and immediately closes
Agent commands inside WSL continue to work

greg-mcnamara-datacom · 18 days ago

I have the same problem in Windows app version 26.803.41515. This had been working perfectly up until the few days, so I suspect the feature was broken in a recent update.

Agitatree · 17 days ago

Still reproducible in windows package 26.803.81509
Environment:

Window 11 25H2 Build 26200.8875
WSL Version 2.7.10.0
Ubuntu 26.04

fenicottero-loriot · 17 days ago

Updated behavior on Codex Desktop for Windows 26.803.10989.0.

The original renderer early-return failure appears to have progressed further in this build: with Agent environment set to WSL and integrated terminal shell set to WSL, opening the terminal now causes ChatGPT.exe to spawn a real wsl.exe child. However, the child survives for only about 39 ms, exits, and the terminal panel immediately collapses.

Controlled comparisons:

Direct wsl.exe -d Ubuntu from the exact same WSL UNC workspace succeeds, enters the expected /home/<wsl-user> directory, and exits 0.
Ubuntu, bash, Git, and the WSL app-server are healthy.
Changing only the Agent environment to Windows, while leaving the integrated terminal shell set to WSL, produces a stable working WSL terminal in the same workspace.
The same nvm/npm startup warning is visible in the working configuration, so it is not the terminal-exit trigger.

This narrows the remaining failure to the WSL-Agent-specific terminal host / PTY / session-attachment path rather than WSL itself, UNC cwd translation, or the WSL terminal-shell selection.

I captured the parent/child relationship and lifetime, but not the short-lived child's full command line or exit code. Therefore this is evidence for the failure boundary, not a claim about the final internal exception. It is also a useful regression distinction from 26.730.8199.0, where prior diagnostics showed the terminal action could fail before a WSL/PTY child was created.

Expected behavior remains: terminal-host failures should retain a visible tab with an actionable error, and Windows-Agent/WSL-Agent terminal launch should use the same validated WSL cwd and shell-launch path.

fenicottero-loriot · 17 days ago

Follow-up after inspecting the current package and comparing the legacy and remote WSL terminal paths.

Environment/version clarification:

MSIX package: OpenAI.Codex_26.803.10989.0_x64__2p2nqsd0c76g0
Bundled/About build observed: 26.803.81509
WSL2 distro: Ubuntu
Active task cwd: /home/<wsl-user>
Active task host: local
Effective desktop settings:

[desktop]
runCodexInWindowsSubsystemForLinux = true
integratedTerminalShell = "wsl"
defaultTerminalLocation = "bottom"

The important additional distinction is that runCodexInWindowsSubsystemForLinux = true now selects the deprecated legacy WSL agent environment, not the newer WSL-connection host architecture. The current package contains UI text directing legacy users to open a project from a WSL connection instead, and it contains a dedicated WSL remote host/terminal backend. A WSL remote host would have an identity such as remote-wsl:<distro> and would start the POSIX terminal session inside that host.

This affected task is still hostId=local, and no remote-wsl:Ubuntu project/connection is exposed in the current client state.

For the legacy local-host route, the Linux cwd is normalized to a WSL UNC path (conceptually \\wsl$\Ubuntu\home\<wsl-user>) and then used by the Windows-local PTY/ConPTY launch path. In the controlled Windows-agent case, Linux-path conversion is not active: the local terminal launcher falls back to a safe Windows cwd, starts wsl.exe, and then initializes the shell cwd inside WSL. That route remains stable.

This refines the earlier 39 ms observation:

Windows agent + PowerShell terminal: works
Windows agent + WSL terminal: works
Legacy WSL agent + integrated terminal: wsl.exe is spawned by ChatGPT.exe, exits after about 39 ms, and the panel collapses
Direct wsl.exe -d Ubuntu and normal WSL agent commands work

A correction to my previous comment: saying the comparison ruled out "UNC cwd translation" was too broad. The direct WSL command proves WSL itself is healthy, but it does not prove that the Windows-local node-pty/ConPTY launch path handles the same WSL UNC cwd and legacy session initialization correctly. The failing boundary is the combination of legacy WSL-agent cwd normalization, the local PTY backend, and terminal session attachment; UNC syntax by itself has not been isolated as the sole cause.

The Desktop log still does not retain a terminal-specific backend error. After the panel flashes closed, the task reports that no app terminal session is attached. The renderer also emits a burst of ResizeObserver loop completed with undelivered notifications messages while the panel opens/collapses, but those look like UI fallout and are not sufficient to identify the backend exception.

Confirming — still broken on my machine (2026-08-12)

Environment

OS: Windows 11 Home 25H2
WSL2 + Ubuntu
Codex Desktop (Microsoft Store): 26.803.10989.0
Agent environment: WSL
Open terminal from side panel “终端”

Symptom

Click Terminal → panel flashes / closes immediately → no usable terminal tab.

Checks

WSL and git work normally outside Codex
Same as #37104 / #37962

Please prioritize: optional Git probe failure should not kill the integrated terminal.
Related: #35119

rublaman · 10 days ago

Still reproducible as of 2026-08-18 on Codex App 26.810.7004.0 from the Microsoft Store.

My setup is Windows 11 with WSL2 and Ubuntu 24.04, with:

[desktop]
runCodexInWindowsSubsystemForLinux = true
integratedTerminalShell = "wsl"

Clicking the terminal button still makes the panel appear briefly and immediately close, leaving no usable terminal session. WSL and Git continue to work normally outside Codex. Selecting PowerShell as the integrated terminal does not help while the Codex agent environment remains set to WSL.

The Store currently reports that the app is fully up to date. The detailed trace from this machine is documented in #37962.

hcmak · 9 days ago

Confirmed on current Windows package 26.814.5167.0 — root cause isolated and locally patched successfully.

Environment:

Windows 11 x64
WSL2 / Ubuntu
Codex package: OpenAI.Codex_26.814.5167.0_x64__2p2nqsd0c76g0
Agent runtime: WSL
Integrated terminal shell: WSL

Reproduction:

With Agent runtime = Windows, both PowerShell and WSL terminals work.
With Agent runtime = WSL, both PowerShell and WSL terminal options cause the bottom terminal panel to flash and immediately close.

I instrumented the shipped 26.814.5167.0 renderer and terminal session manager.

The immediate panel close is only cleanup. The actual failure is a terminal-host error:

Git is unavailable

The renderer receives the terminal error event, calls deleteSessionMapping(sessionId), the terminal session disappears from the conversation snapshot, and the bottom-panel cleanup then removes the terminal tab and closes the empty panel.

Importantly, Git itself is available inside the WSL terminal:

DISTRO=Ubuntu

/usr/bin/git

git version 2.43.0

I isolated the failing call in the main-process Terminal Manager initialization. The terminal receives a getWorktreeShellEnvironmentForCwd callback equivalent to:

async t => {
let r = await e.gitManager.getWorktreeRepository(n.ho(t), s);
return r == null ? null : n.X(r);
}

When getWorktreeRepository() throws Git is unavailable, this optional Git/worktree environment lookup aborts terminal creation.

I changed only this callback to fail open:

async t => {
try {
return (t = await e.gitManager.getWorktreeRepository(n.ho(t), s)) && n.X(t);
} catch {}
}

No renderer cleanup changes, routing changes, or terminal-session hacks are required.

After applying only this change to the original 26.814.5167.0 ASAR:

WSL Agent runtime works
integrated WSL terminal stays open
PTY is actually running inside Ubuntu/WSL2
uname, pwd, filesystem operations and /usr/bin/git all work normally

So for this reproduction, the terminal is being killed by an optional Git/worktree shell-environment lookup that throws instead of degrading to null.

This may also be related to #35119 (Git is unavailable in valid WSL repositories) and the older symptom report #25256.

A likely upstream fix is to make getWorktreeShellEnvironmentForCwd fail-open when Git/worktree detection is unavailable, rather than failing terminal creation.

echkenluo · 8 days ago

Still reproducible on 2026-08-20 with the newer Windows Store package:

Codex package: OpenAI.Codex_26.814.5517.0_x64__2p2nqsd0c76g0
Windows: 10.0.26200
WSL2: Ubuntu 24.04.4 LTS, kernel 6.6.87.2-microsoft-standard-WSL2
WSL Codex CLI: codex-cli 0.146.0
Git in WSL: git version 2.43.0

This reproduction is useful because the affected folder-backed task is running through the current managed WSL connection route (remote-ssh-codex-managed:wsl), not the deprecated legacy hostId=local WSL-agent route discussed above.

The persisted desktop settings are also different from the original report:

[desktop]
integratedTerminalShell = "powershell"
runCodexInWindowsSubsystemForLinux = false

The task itself still executes normally inside WSL and its app-server connection is healthy. However, on the existing session page:

the terminal button does not create a usable terminal tab;
Ctrl+` is a silent no-op;
task-level terminal inspection returns No app terminal session is attached to this thread yet.;
no terminal/PTY creation or terminal-specific backend error is recorded around the action.

The Microsoft Store reports that no newer package is available.

So the terminal/session-attachment failure is still present in 26.814.5517.0, and it can also reproduce on the managed WSL connection path. This trace does not establish whether the optional Git/worktree-environment failure identified in the previous comment is the trigger here; the directly verified boundary is that no app terminal session becomes attached.

rublaman · 7 days ago

Still reproducible as of 2026-08-21 after updating Codex from 26.810.7004.0 to 26.818.31338.

The configuration on the same Windows 11 / WSL2 / Ubuntu 24.04 machine remains:

[desktop]
runCodexInWindowsSubsystemForLinux = true
integratedTerminalShell = "wsl"

After the update, clicking the terminal button still makes the panel flash briefly and close immediately without leaving a usable terminal session. WSL and Git continue to work normally outside the Codex integrated terminal, so the update has not resolved the issue on this machine.

masterjaso · 6 days ago

I too am getting this issue with the terminal flash and close immediately. No error message no way to triage, troubleshoot, or correct. I am trying WSL2 with Ubuntu 26 distro. Hasn't worked for a few weeks now - very buggy and poor UX.

Tried both side and bottom panels. Side panel if I open Files it works, then when I try to add terminal, the brief flash and disappear when I try to add it.

Codex Windows App Version: 26.818.31338 (updated just before this post was made)

rbogasch · 4 days ago

Current Store build `26.818.5229.0`: terminal Git-enrichment path remains unguarded

Cross-linking #37962 with evidence from a newer installed package.

I inspected an isolated copy of OpenAI.Codex_26.818.5229.0_x64__2p2nqsd0c76g0 (app.asar SHA-256 C5D839BC9B122B7EF2A2F0F45186B3E5895923DE5B6CEF5253C936FE670C0479). The terminal manager still contains one unguarded callback equivalent to:

async cwd => {
  const repository = await gitManager.getWorktreeRepository(toPlatformPath(cwd), appServerClient);
  return repository == null ? null : getWorktreeShellEnvironment(repository);
}

If the Git worker rejects with Git is unavailable, this optional environment-enrichment step can still abort terminal creation before PTY startup.

An isolated, byte-length-preserving A/B patch changed only that callback to catch the repository lookup and return null. Validation on the exact runtime matched one terminal site, preserved the ASAR byte length, and allowed terminal creation to proceed without Git enrichment. This is diagnostic confirmation; users should not need to patch a copied Store runtime.

The production behavior should be a normal error boundary with logging:

let repository = null;
try {
  repository = await gitManager.getWorktreeRepository(cwd, appServerClient);
} catch (error) {
  logger.warn("Git/worktree enrichment failed; starting terminal without it", { error });
}

return repository ? await getWorktreeShellEnvironment(repository) : null;

The Git probe itself must also be fixed, but Git capability detection and terminal availability are separate concerns: failure of the former must never silently destroy the latter.

The complete failure chain, impact assessment, clean fix, and regression-test proposal are documented here: https://github.com/openai/codex/issues/37962#issuecomment-5391032851

Please link the internal fix/owner and identify the first Microsoft Store build expected to contain the terminal failure-isolation change.

daisaki51 · 4 days ago

I can reproduce the same silent no-op on a Windows-native local folder-backed task (not a WSL project) with Microsoft Store package OpenAI.Codex_26.818.5345.0_x64__2p2nqsd0c76g0.

All entry points fail:

View → Open Terminal
View → Toggle Bottom Panel
Ctrl+`
Ctrl+J

No panel or terminal session is created; the app reports that no terminal session is attached to the thread. External Windows Terminal and PowerShell work normally, and npm run dev runs successfully there.

I reproduced this after:

restarting Windows and the app
running Windows app Repair
updating from 26.818.5229.0 to 26.818.5345.0
resetting only the affected thread's persisted panel route state
regenerating the Electron renderer cache

The app log repeatedly emits:
ResizeObserver loop completed with undelivered notifications.

This suggests the route/thread-scope regression described in this issue also affects Windows-native existing local-thread routes, not only WSL-configured tasks. No private paths, task IDs, account IDs, or raw logs are included.

greg-mcnamara-datacom · 3 days ago

This problem is still reproducible in version 26.818.61809 (just updated this morning).

Lee-Ju-Yeong · 3 days ago

Still reproducible on Microsoft Store package 26.818.8289.0.

Additional finding: the trigger appears to be the Agent Environment setting, not only the integrated terminal shell.

Test matrix:

Agent environment: Windows native
Integrated terminal: PowerShell
Result: terminal opens normally

Agent environment: Windows Subsystem for Linux
Integrated terminal: PowerShell
Result: terminal does not open

Agent environment: Windows Subsystem for Linux
Integrated terminal: Command Prompt
Result: terminal does not open

Agent environment: Windows Subsystem for Linux
Integrated terminal: Git Bash
Result: terminal does not open

Agent environment: Windows Subsystem for Linux
Integrated terminal: WSL
Result: terminal does not open

The app was fully restarted and a new thread was created after changing the settings.

WSL itself is healthy:

Ubuntu / WSL2
wsl.exe works outside Codex
interactive PTY works: /dev/pts/3
the issue reproduces both with a Windows-hosted project and a WSL-filesystem test project

This suggests runCodexInWindowsSubsystemForLinux=true prevents integrated terminal session creation regardless of integratedTerminalShell.

Codex feedback session ID: 01a03697-defc-7d72-b2f4-d1014e2b558f

renanfranca · 2 days ago

Why did you close, @cxzhong ? Did you find a fix?

cxzhong · 2 days ago

Why did you close, @cxzhong ? Did you find a fix?

The lastest version fixes this

[Windows][WSL][26.730.8199.0] Integrated terminal silently fails before PTY/WSL startup; bottom and side panel cannot open

What version of the Codex App are you using?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

Desktop configuration

Steps to reproduce

Expected behavior

Actual behavior

Diagnostic evidence

1. WSL itself is healthy

2. Terminal action never reaches the PTY backend

3. The shipped renderer contains a route/thread-ID mismatch

4. The global terminal-command fallback also lacks route scope

Why this appears to be a Desktop routing/session-ownership regression

Suggested fix

Regression coverage

Additional information

22 Comments

How I isolated it

Temporary workaround for other users

Confirming — still broken on my machine (2026-08-12)

Environment

Symptom

Checks

Current Store build 26.818.5229.0: terminal Git-enrichment path remains unguarded

Current Store build `26.818.5229.0`: terminal Git-enrichment path remains unguarded