[macOS][Desktop 26.825.32147] Local project task loses shell/filesystem tools; terminal cannot attach

[storagebit]

What version of Codex are you using?

Codex Desktop 26.825.32147, released August 28, 2026.

Platform

macOS. Exact Darwin version and architecture are unavailable from this task because the local shell runner is missing.

What issue are you seeing?

A fresh local Codex project task has no usable shell runner or normal filesystem inspection tools, so the agent cannot compile, inspect the workspace, or run even basic diagnostics.

This is not a Rust/project compile error. No command reaches Cargo, the sandbox, or approval handling.

Observed behavior

In a local project task:

• The model-visible tool catalog contains Codex app/thread tools and apply_patch, but no shell/exec_command runner and no ordinary file-reading tool.
• A spawned subagent inherited the same missing shell/filesystem capability.
• read_thread_terminal returns:

No app terminal session is attached to this thread yet.

• Requesting an integrated terminal only returns:

{"status":"queued","threadId":"01a04ada-f0f2-7322-b2f2-b1f74b0d281e"}

• A follow-up terminal read still reports:

No app terminal session is attached to this thread yet.

• The saved project inventory reported the expected local project path but marked it as isGitRepository:false; path details are omitted here to avoid publishing local user information.
• Recreating/restarting with a brand-new local project did not resolve the missing runner.
• Changing models did not recover this existing task.

Expected behavior

A local Codex project task should receive the normal local coding tool surface, including shell execution and scoped filesystem access. Asking the agent to compile a Rust workspace should allow it to run commands such as:

cargo fmt --all -- --check
cargo clippy --workspace --all-targets --all-features -- -D warnings
cargo test --workspace --all-features
cargo build --workspace --release

Actual impact

Local coding work is completely blocked in Codex Desktop. The agent cannot inspect files, cannot run cargo, cannot verify the project, and cannot distinguish a real build failure from an app tool-provisioning failure.

Reproduction outline

1. Use Codex Desktop 26.825.32147 on macOS.
2. Create or open a fresh local project task.
3. Ask Codex to run a local command or compile a Rust workspace.
4. Observe that no shell runner is available to the task.
5. Try opening/reading the integrated terminal.
6. Observe that read_thread_terminal reports no terminal session attached.

Related reports

This appears related to, but distinct from:

• Codex Desktop GPT-5.6 models fail to run exec tool: code-mode host exits during handshake #41255: 26.825.x GPT-5.6 code-mode exec failures.
• Codex Desktop macOS: read_thread_terminal cannot see a working integrated terminal #31417: macOS read_thread_terminal cannot see an attached terminal.
• [Bug] Global Tool-Calling Regression: Native tools drop and raw <thinking> tags leak across sessions during model switching #39774: macOS native tools/tool catalog dropping across sessions.
• [macOS][Desktop] Task started from Codex is persisted as ChatGPT and loses Codex/browser skills #41409: exact 26.825.32147 build showing session routing/capability provisioning problems.

The distinguishing symptom here is that a macOS local project task on 26.825.32147 is provisioned without the shell/filesystem tools needed for local coding at all, and the terminal attachment workaround does not recover them.

[github-actions]

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

• [Bug] Codex Desktop's built-in terminal cannot attach to the current chat and continuously returns queued #40338

Powered by Codex Action

[Quinn-XIII]

I’m seeing a closely related issue on macOS with ChatGPT.app 26.825.51511.

Important difference from the original report: backend shell/tool execution still works in my task. The agent can run commands and generate files, but the integrated terminal UI never appears.

Observed:

• View > Open Terminal does nothing.
• View > Toggle Bottom Panel does nothing.
• Changing terminal placement from bottom to right does not help.
• Creating a new Codex task does not help.
• Signing out/in does not help.
• Reinstalling ChatGPT.app does not help.
• Restarting macOS does not help.
• Agent-side open terminal call returns:
  {"status":"queued","threadId":"01a05636-be2b-7241-9016-0fc1093581e3"}

File previews in the side panel do work, so the side panel itself is not completely broken. The failure seems isolated to integrated terminal attachment / bottom panel routing.

[jianghao-zhang]

Reproduced on ChatGPT.app 26.825.41651 / macOS 27.0.

The bundled node-pty resolves spawn-helper to:

.../app.asar.unpacked.unpacked/node_modules/node-pty/build/Release/spawn-helper

The extra .unpacked comes from unixTerminal.js unconditionally replacing app.asar with app.asar.unpacked even when native.dir is already under app.asar.unpacked. The resolved file does not exist, so pty.fork throws Error: posix_spawnp failed. and no terminal session attaches.

Passing the actual helper path under app.asar.unpacked to the native PTY module successfully starts a shell. Please make the path rewrite conditional, or normalize a repeated .unpacked suffix.

[jianghao-zhang]

Still reproducible after updating to ChatGPT.app 26.831.11858 on macOS 27.0.

Additional regression: while voice is enabled, the integrated-terminal controls are non-interactive. Clicks on Open Terminal and Toggle Bottom Panel have no effect, so the terminal cannot be opened or retried while voice is active.

[fine405]

Reproduced on Codex Desktop 26.825.51511 on macOS.

In this case, backend shell execution still works, but the integrated terminal UI cannot be opened:

• Requesting an integrated terminal returns queued.
• read_thread_terminal continues to report: No app terminal session is attached to this thread yet.
• Restarting the terminal interaction does not attach a visible terminal session.

The Xcode license has already been accepted and the first-launch setup completed successfully, so the Xcode-license workaround does not apply here.

Local inspection of the bundled node-pty code matches the packaging-path problem described in this thread:

• The actual helper exists at .../app.asar.unpacked/node_modules/node-pty/build/Release/spawn-helper.
• unixTerminal.js unconditionally runs helperPath.replace('app.asar', 'app.asar.unpacked').
• Because the path already contains app.asar.unpacked, this produces the nonexistent path .../app.asar.unpacked.unpacked/node_modules/node-pty/build/Release/spawn-helper.

This strongly suggests that build 26.825.51511 is affected by the same node-pty spawn-helper packaging regression. This also appears related to #29090.

[fine405]

An upstream fix for the confirmed node-pty helper-path regression already exists: microsoft/node-pty#924 (open, not yet merged). The underlying upstream issue is microsoft/node-pty#923.

The PR prevents the unconditional app.asar → app.asar.unpacked rewrite from running when the path is already unpacked, avoiding the nonexistent app.asar.unpacked.unpacked/.../spawn-helper path verified in Codex Desktop 26.825.51511.

A likely downstream resolution is to cherry-pick the equivalent guard into the bundled dependency, or update node-pty after the upstream fix is merged and released.