[macOS][Desktop] Integrated terminal disappears when Git/worktree environment lookup fails before PTY creation

Summary

On Apple Silicon macOS, both Toggle Bottom Panel and Open Terminal briefly showed the terminal area and then closed it. The shell itself was functional. Git availability checking failed because the system Git/xcrun entry point ran in a translated process and could not load a compatible x86_64 Command Line Tools library.

The desktop terminal startup path propagated this Git/worktree lookup failure before creating the PTY. The frontend removed the failed terminal session and its tab, causing the empty panel to close without leaving a persistent actionable error.

Environment

• macOS: 26.6.2, Apple Silicon
• Desktop version: 26.908.40834, build 8881
• Bundled Codex CLI observed during diagnosis: 0.154.0-alpha.6.2
• Desktop main executable: arm64
• Affected command execution context: sysctl.proc_translated=1, uname -m=x86_64
• Shell: /bin/zsh
• Native Apple Git: 2.54.0 (Apple Git-157)

The translated command context should not be confused with the architecture of the desktop main executable. The reason that command execution selected Rosetta was not established.

Observed reproduction

1. Use an affected macOS environment in which PATH resolves git to /usr/bin/git and the translated Git/xcrun command fails with the error below.
2. Open a local repository task in the desktop app.
3. Invoke Toggle Bottom Panel (Cmd+J), or Open Terminal (Control+backtick).
4. The panel briefly appears and immediately closes. No terminal session remains associated with the task.

This was observed in the affected installation. A separate clean-machine reproduction or injected-failure fixture has not been run.

Actual vs expected

Actual: failure to retrieve Git/worktree environment data prevents the shell/PTY from being created, and the UI removes the terminal tab.

Expected: a failure in optional Git-derived enrichment should not silently destroy the terminal. Preserve all required environment and policy restrictions; where safe, launch with the normal base environment and show the Git warning. If startup must be blocked, keep a visible error with a retry action.

Evidence

The desktop log repeatedly reported:

Failed to apply worktree shell environment config ... Git is unavailable

The same Git availability probe used by the installed client exited with code 1. The underlying command reported:

xcrun: error: unable to load libxcrun
... libxcrun.dylib ... missing compatible architecture
(have 'arm64,arm64e', need 'x86_64')

A normal interactive login zsh command completed successfully. Both of the following Git commands also worked:

arch -arm64 /usr/bin/git --version
/Library/Developer/CommandLineTools/usr/bin/git --version

Read-only inspection of the installed JavaScript traced the path:

createLocalTerminalBackend
  -> await buildTerminalEnv
  -> await gitManager.getWorktreeRepository
  -> GitUnavailableError
  -> terminal error event
  -> frontend deletes session mapping
  -> terminal tab removed
  -> empty bottom panel closes

The relevant installed assets were main-DaMR-wdT.js, src-CCXHtyvY.js, app-initial-9b95fa538c62.js, and runtime-fe24efad5cce.js. No application bundle was modified.

Local workaround and verification

A user-level PATH wrapper was added at ~/.local/bin/git:

#!/bin/sh
exec /Library/Developer/CommandLineTools/usr/bin/git "$@"

This bypassed the failing xcrun entry point and preserved the native Git helper-program path. No system binary, application bundle, shell startup file, or Codex config was changed for this workaround.

Afterward:

• The same Git availability probe exited successfully.
• Git worked even when called from an explicitly x86_64 /bin/sh.
• git --exec-path returned /Library/Developer/CommandLineTools/usr/libexec/git-core.
• Repository-root discovery worked in both checked repositories.
• The Codex terminal API returned a live zsh session and a normal prompt including the branch name.
• The task layout contained a terminal tab with bottom.open=true, compared with no terminal session and an empty closed panel before the workaround.

This is a local workaround, not a fix to the application's error handling.

Related report

Related: https://github.com/openai/codex/issues/37962

#37962 describes the same downstream Git-enrichment/terminal-cleanup failure path on Windows/WSL. Its reporter later confirmed recovery in Windows app 26.825.41651 and closed it. This report supplies a different macOS trigger in a later desktop version; it does not assume the Windows command-construction problem is present on macOS or that the previous fix was reverted.

Suggested regression coverage

• Fail the optional Git availability/worktree lookup while a plain shell remains launchable; verify safe fallback or a persistent useful error.
• Verify frontend startup errors are not lost when a session has not attached yet.
• Exercise Apple Silicon environments where a Git shim is unusable but a valid native Git executable exists.

Only sanitized findings are included here. Full config files, credentials, session transcripts, private repository paths, and usernames are intentionally omitted.

Start at the desktop terminal startup path described in createLocalTerminalBackend, following buildTerminalEnv and gitManager.getWorktreeRepository through the terminal error event and frontend session cleanup. Use the suggested regression scenarios to verify that a failed optional Git/worktree lookup leaves a usable PTY or a persistent actionable error, including the Apple Silicon Git-shim case.