Windows Codex app: file-edit approval buttons are unresponsive in Remote SSH conversations, while CLI approval works

Open 💬 11 comments Opened Jul 22, 2026 by johnnyy775

What version of Codex CLI is running?

codex-cli 0.144.6

What subscription do you have?

ChatGPT Plus

Which model were you using?

gpt-5.6-sol, any reasoning effort

What platform is your computer?

Microsoft Windows 11 NT x64 26220.8690, Remote host: Debian 13.6, 6.12.95+deb13-amd64

What terminal emulator and version are you using (if applicable)?

Windows Terminal, Windows PowerShell 5.1 and OpenSSH, connected to Debian 13.6 over SSH.

Codex doctor report

{
  "schemaVersion": 1,
  "generatedAt": "1784682784s since unix epoch",
  "overallStatus": "ok",
  "codexVersion": "0.144.6",
  "checks": {
    "app_server.status": {
      "id": "app_server.status",
      "category": "app-server",
      "status": "ok",
      "summary": "background server is running",
      "details": {
        "app-server version": "0.144.6",
        "control socket": "/home/codex-agent/.codex/app-server-control/app-server-control.sock",
        "daemon state dir": "/home/codex-agent/.codex/app-server-daemon",
        "mode": "ephemeral",
        "pid file": "/home/codex-agent/.codex/app-server-daemon/app-server.pid (missing)",
        "settings": "/home/codex-agent/.codex/app-server-daemon/settings.json (missing)",
        "status": "running",
        "update-loop pid file": "/home/codex-agent/.codex/app-server-daemon/app-server-updater.pid (missing)"
      },
      "remediation": null,
      "durationMs": 89
    },
    "auth.credentials": {
      "id": "auth.credentials",
      "category": "auth",
      "status": "ok",
      "summary": "auth is configured",
      "details": {
        "auth file": "/home/codex-agent/.codex/auth.json",
        "auth storage mode": "File",
        "stored API key": "false",
        "stored ChatGPT tokens": "true",
        "stored agent identity": "false",
        "stored auth mode": "chatgpt"
      },
      "remediation": null,
      "durationMs": 0
    },
    "config.load": {
      "id": "config.load",
      "category": "config",
      "status": "ok",
      "summary": "config loaded",
      "details": {
        "CODEX_HOME": "/home/codex-agent/.codex",
        "config.toml": "/home/codex-agent/.codex/config.toml",
        "config.toml parse": "ok",
        "cwd": "/srv/codex-matrix",
        "enabled feature flags": "shell_tool, unified_exec, shell_snapshot, code_mode_host, terminal_resize_reflow, sqlite, hooks, enable_request_compression, multi_agent, apps, tool_search_always_defer_mcp_tools, tool_suggest, plugins, in_app_browser, browser_use, browser_use_full_cdp_access, browser_use_external, computer_use, remote_plugin, plugin_sharing, image_generation, resize_all_images, skill_mcp_dependency_install, mentions_v2, steer, guardian_approval, goals, collaboration_modes, tool_call_mcp_elicitation, auth_elicitation, personality, fast_mode, tui_app_server, remote_compaction_v2, workspace_dependencies",
        "feature flag overrides": "none",
        "feature flags enabled": "35",
        "log dir": "/home/codex-agent/.codex/log",
        "mcp servers": "0",
        "model": "gpt-5.6-sol",
        "model provider": "openai",
        "sqlite home": "/home/codex-agent/.codex"
      },
      "remediation": null,
      "durationMs": 0
    },
    "git.environment": {
      "id": "git.environment",
      "category": "git",
      "status": "ok",
      "summary": "git version 2.47.3",
      "details": {
        ".git entry": "directory",
        "PATH git #1": "/usr/bin/git",
        "PATH git #2": "/bin/git",
        "PATH git entries": "2",
        "git branch": "main",
        "git build options": "git version 2.47.3; cpu: x86_64; no commit associated with this build; sizeof-long: 8; sizeof-size_t: 8; shell-path: /bin/sh; libcurl: 8.14.1; zlib: 1.3.1",
        "git exec path": "/usr/lib/git-core",
        "git version": "git version 2.47.3",
        "repo detected": "true",
        "repo root": "/srv/codex-matrix",
        "selected git": "/usr/bin/git"
      },
      "remediation": null,
      "durationMs": 62
    },
    "installation": {
      "id": "installation",
      "category": "install",
      "status": "ok",
      "summary": "installation looks consistent",
      "details": {
        "PATH codex #1": "/home/codex-agent/.local/bin/codex",
        "PATH codex #2": "/home/codex-agent/.local/bin/codex",
        "PATH codex entries": "2",
        "current executable": "/home/codex-agent/.codex/packages/standalone/releases/0.144.6-x86_64-unknown-linux-musl/bin/codex",
        "install context": "standalone (unix, package /home/codex-agent/.codex/packages/standalone/releases/0.144.6-x86_64-unknown-linux-musl, bin /home/codex-agent/.codex/packages/standalone/releases/0.144.6-x86_64-unknown-linux-musl/bin, resources /home/codex-agent/.codex/packages/standalone/releases/0.144.6-x86_64-unknown-linux-musl/codex-resources, path /home/codex-agent/.codex/packages/standalone/releases/0.144.6-x86_64-unknown-linux-musl/codex-path)",
        "managed by bun": "false",
        "managed by npm": "false",
        "managed by pnpm": "false",
        "managed package root": "not set"
      },
      "remediation": null,
      "durationMs": 1
    },
    "mcp.config": {
      "id": "mcp.config",
      "category": "mcp",
      "status": "ok",
      "summary": "no MCP servers configured",
      "details": {},
      "remediation": null,
      "durationMs": 0
    },
    "network.env": {
      "id": "network.env",
      "category": "network",
      "status": "ok",
      "summary": "network-related environment looks readable",
      "details": {
        "proxy env vars": "none"
      },
      "remediation": null,
      "durationMs": 0
    },
    "network.provider_reachability": {
      "id": "network.provider_reachability",
      "category": "reachability",
      "status": "ok",
      "summary": "active provider endpoints are reachable over HTTP",
      "details": {
        "ChatGPT base URL": "https://chatgpt.com/backend-api/ reachable (HTTP 403)",
        "reachability mode": "ChatGPT auth"
      },
      "remediation": null,
      "durationMs": 160
    },
    "network.websocket_reachability": {
      "id": "network.websocket_reachability",
      "category": "websocket",
      "status": "ok",
      "summary": "Responses WebSocket handshake succeeded",
      "details": {
        "DNS": "2 IPv4, 2 IPv6, first IPv4",
        "auth mode": "chatgpt",
        "connect timeout": "15000 ms",
        "endpoint": "wss://chatgpt.com/backend-api/<redacted>",
        "handshake result": "HTTP 101 Switching Protocols",
        "model provider": "openai",
        "models etag present": "true",
        "provider name": "OpenAI",
        "proxy env vars": "none",
        "reasoning header": "false",
        "server model present": "false",
        "supports websockets": "true",
        "wire API": "responses"
      },
      "remediation": null,
      "durationMs": 823
    },
    "runtime.provenance": {
      "id": "runtime.provenance",
      "category": "runtime",
      "status": "ok",
      "summary": "running standalone on linux-x86_64",
      "details": {
        "commit": "unknown",
        "current executable": "/home/codex-agent/.codex/packages/standalone/releases/0.144.6-x86_64-unknown-linux-musl/bin/codex",
        "install method": "standalone (unix, package /home/codex-agent/.codex/packages/standalone/releases/0.144.6-x86_64-unknown-linux-musl, bin /home/codex-agent/.codex/packages/standalone/releases/0.144.6-x86_64-unknown-linux-musl/bin, resources /home/codex-agent/.codex/packages/standalone/releases/0.144.6-x86_64-unknown-linux-musl/codex-resources, path /home/codex-agent/.codex/packages/standalone/releases/0.144.6-x86_64-unknown-linux-musl/codex-path)",
        "platform": "linux-x86_64",
        "version": "0.144.6"
      },
      "remediation": null,
      "durationMs": 0
    },
    "runtime.search": {
      "id": "runtime.search",
      "category": "search",
      "status": "ok",
      "summary": "search is OK (bundled)",
      "details": {
        "search command": "/home/codex-agent/.codex/packages/standalone/releases/0.144.6-x86_64-unknown-linux-musl/codex-path/rg",
        "search command readiness": "file exists",
        "search provider": "bundled"
      },
      "remediation": null,
      "durationMs": 0
    },
    "sandbox.helpers": {
      "id": "sandbox.helpers",
      "category": "sandbox",
      "status": "ok",
      "summary": "sandbox configuration is readable",
      "details": {
        "approval policy": "UnlessTrusted",
        "codex-linux-sandbox helper": "/home/codex-agent/.codex/tmp/arg0/codex-arg0M0TZMo/codex-linux-sandbox",
        "execve wrapper helper": "/home/codex-agent/.codex/tmp/arg0/codex-arg0M0TZMo/codex-execve-wrapper",
        "filesystem sandbox": "restricted",
        "network sandbox": "restricted"
      },
      "remediation": null,
      "durationMs": 0
    },
    "state.paths": {
      "id": "state.paths",
      "category": "state",
      "status": "ok",
      "summary": "state paths and databases are inspectable",
      "details": {
        "CODEX_HOME": "/home/codex-agent/.codex (dir)",
        "active rollout files": "5 files, 2332051 total bytes, 466410 average bytes",
        "archived rollout files": "1 files, 65982 total bytes, 65982 average bytes",
        "goals DB": "/home/codex-agent/.codex/goals_1.sqlite (file)",
        "goals DB integrity": "ok",
        "log DB": "/home/codex-agent/.codex/logs_2.sqlite (file)",
        "log DB integrity": "ok",
        "log dir": "/home/codex-agent/.codex/log (dir)",
        "memories DB": "/home/codex-agent/.codex/memories_1.sqlite (file)",
        "memories DB integrity": "ok",
        "sqlite home": "/home/codex-agent/.codex (dir)",
        "standalone release cache": "3 entries in /home/codex-agent/.codex/packages/standalone/releases",
        "state DB": "/home/codex-agent/.codex/state_5.sqlite (file)",
        "state DB integrity": "ok"
      },
      "remediation": null,
      "durationMs": 140
    },
    "state.rollout_db_parity": {
      "id": "state.rollout_db_parity",
      "category": "threads",
      "status": "ok",
      "summary": "rollout files and state DB thread inventory agree",
      "details": {
        "default model provider": "openai",
        "rollout DB active files": "5",
        "rollout DB active rows": "5",
        "rollout DB archive mismatches": "0",
        "rollout DB archived files": "1",
        "rollout DB archived rows": "1",
        "rollout DB duplicate DB paths": "0",
        "rollout DB duplicate rollout thread ids": "0",
        "rollout DB malformed file names": "0",
        "rollout DB missing active rows": "0",
        "rollout DB missing archived rows": "0",
        "rollout DB model providers": "openai=6",
        "rollout DB rows": "6",
        "rollout DB scan cap reached": "false",
        "rollout DB scan errors": "0",
        "rollout DB sources": "vscode=5, cli=1",
        "rollout DB stale rows": "0"
      },
      "remediation": null,
      "durationMs": 161
    },
    "system.environment": {
      "id": "system.environment",
      "category": "system",
      "status": "ok",
      "summary": "OS language en-US",
      "details": {
        "EDITOR": "not set",
        "LANG": "en_US.UTF-8",
        "VISUAL": "not set",
        "os": "Debian 13.0.0 (trixie) [64-bit]",
        "os language": "en-US",
        "os type": "Debian",
        "os version": "13.0.0"
      },
      "remediation": null,
      "durationMs": 12
    },
    "terminal.env": {
      "id": "terminal.env",
      "category": "terminal",
      "status": "ok",
      "summary": "terminal metadata was detected",
      "details": {
        "SSH_CLIENT": "present",
        "SSH_CONNECTION": "present",
        "SSH_TTY": "present",
        "TERM": "xterm-256color",
        "color output": "enabled",
        "effective locale": "en_US.UTF-8",
        "stderr is terminal": "true",
        "stdin is terminal": "true",
        "stdout is terminal": "true",
        "terminal": "unknown",
        "terminal size": "92x51"
      },
      "remediation": null,
      "durationMs": 0
    },
    "terminal.title": {
      "id": "terminal.title",
      "category": "title",
      "status": "ok",
      "summary": "terminal title default",
      "details": {
        "terminal title activity": "true",
        "terminal title items": "activity, project-name",
        "terminal title project source": "git repo root",
        "terminal title project value": "codex-matrix",
        "terminal title source": "default"
      },
      "remediation": null,
      "durationMs": 0
    },
    "updates.status": {
      "id": "updates.status",
      "category": "updates",
      "status": "ok",
      "summary": "update configuration is locally consistent",
      "details": {
        "cached latest version": "0.145.0",
        "check for update on startup": "true",
        "last checked at": "2026-07-22T00:27:31.424642494Z",
        "latest version": "0.145.0",
        "latest version status": "newer version is available",
        "update action": "standalone installer",
        "version cache": "/home/codex-agent/.codex/version.json"
      },
      "remediation": null,
      "durationMs": 226
    }
  }
}

What issue are you seeing?

The Windows ChatGPT/Codex app cannot accept or reject file-edit
approval requests in a synchronized Remote SSH conversation.

Shell-command approvals work normally in the Windows app. However,
when the app displays:

Allow ChatGPT to edit the following file?

both Allow once and Deny are completely unresponsive. Mouse
clicks have no effect, and keyboard focus does not reach the controls
reliably. The conversation remains stuck in the awaiting-approval
state.

The same pending approval is simultaneously visible in the synchronized
Codex CLI conversation on the Debian host. Pressing y in the CLI
immediately accepts the edit. The Windows app then synchronizes,
removes the pending approval, and continues normally.

This indicates that the approval request, Remote SSH connection,
filesystem permissions, and backend processing are functional, while
the Windows app's file-edit approval UI is not.

What steps can reproduce the bug?

Uploaded thread: 019f873e-82b0-7951-ad70-886e9ffc4bcb

What is the expected behavior?

Clicking Allow once should accept the proposed file edit and allow
the conversation to continue.

Clicking Deny should reject the proposed edit and unblock the
conversation.

Both controls should be accessible using mouse and keyboard input.

Additional information

Windows app

  • ChatGPT/Codex for Windows: 26.715.70719
  • Released: July 21, 2026
  • The same problem was previously reproduced on version 26.715.52143.

Local computer

  • Microsoft Windows 11 NT x64 26220.8690
  • Authentication: Sign in with ChatGPT
  • Subscription: ChatGPT Plus

Remote environment

  • Remote SSH host: Debian GNU/Linux 13.6
  • Kernel: 6.12.95+deb13-amd64
  • Codex CLI: 0.144.6
  • Workspace: /srv/codex-matrix

Diagnostics

  • Uploaded feedback thread:

019f873e-82b0-7951-ad70-886e9ffc4bcb

  • Earlier Windows app profile trace:

019f820d-57fb-77a3-88fe-b14cc896f3b0

Updating Codex CLI from 0.144.3 to 0.144.6 did not change the behavior.

The agent responded in Czech because of my existing language
preferences, but the reproduction prompt, approval UI, and all
relevant actions are shown in English. The response language does not
affect the issue.

A screen recording was also provided privately to OpenAI Support (Case ID: 11830910).

<img width="1919" height="1026" alt="Image" src="https://github.com/user-attachments/assets/6140c97f-96d0-41ed-8e43-896fb72cd303" />

<img width="1919" height="1029" alt="Image" src="https://github.com/user-attachments/assets/f33eff5c-79fc-4072-81e4-502cdd9d9175" />

Reproduction steps

  1. Sign in to Codex CLI and the Windows ChatGPT/Codex app using the

same ChatGPT Plus account.

  1. Connect the Windows app to a Remote SSH environment.
  2. Start a new conversation from Codex CLI in the remote workspace.
  3. Open the synchronized conversation in the Windows app.
  4. Ask Codex to run one harmless shell command and then create one

Markdown file using the built-in file-edit action.

  1. Approve the shell command in the Windows app. This works normally.
  2. Wait for the file-edit approval dialog.
  3. Click Allow once. Nothing happens.
  4. Click Deny. Nothing happens.
  5. Switch to the same synchronized conversation in Codex CLI.
  6. Press y to accept the pending file edit.
  7. The edit succeeds immediately and the Windows app synchronizes

and continues normally.

View original on GitHub ↗

11 Comments

ilimc · 1 month ago

I can reproduce the same file-edit approval failure on macOS, with additional logs that point to a Desktop renderer ownership/routing race rather than an SSH, filesystem, remote app-server, or CLI problem.

Environment

  • Codex Desktop for macOS: 26.721.41059
  • Remote Codex/app-server: 0.145.0
  • Remote host: Linux over Desktop Remote SSH
  • Approval policy: on-request, reviewer: user

Important difference from the original report

The affected remote thread was created and operated from Codex Desktop. Codex CLI had not opened or resumed this thread when the first failures occurred, so a CLI client cannot have taken ownership of the approval stream.

Fully rebuilding the remote codex app-server process tree and fully quitting/restarting Desktop did not fix the issue.

Reproduction and log sequence

For a harmless apply_patch file-create approval after a clean Desktop restart:

  1. The visible primary window resumes the remote thread as owner:
rendererWindowAppearance=primary role=owner
  1. A hidden Desktop renderer then resumes the same remote thread and becomes owner:
rendererWindowAppearance=avatarOverlay rendererWindowVisible=false role=owner
  1. The visible primary window is immediately demoted:
rendererWindowAppearance=primary previousRole=owner role=follower ownerClientId=<overlay client>
  1. Clicking the visible file approval button produces:
Failed to forward file approval decision ... errorMessage=no-client-found
rendererWindowAppearance=primary

The thread remains in waitingOnApproval, and the proposed test file is not created.

I also removed selected-avatar-id from the local Desktop config and restarted the app. That disables the visible pet, but the hidden avatarOverlay renderer is still created, still resumes the remote thread, and the failure reproduces. So this does not appear to be caused by a particular pet asset or user-selected avatar; it appears to be the hidden overlay renderer participating in remote thread ownership.

This suggests the file-approval decision is emitted by the visible primary renderer after ownership has moved to a hidden renderer, but the decision is not routed to the current owner. A likely fix would be to prevent non-interactive/hidden overlay renderers from claiming the remote thread's approval stream, or route approval decisions through the actual owner independently of the visible renderer's stream role.

hccnm · 29 days ago

Additional reproduction report (macOS host, SSH remote project; app version not captured):

In the file-edit approval dialog, both Deny and Allow once are completely unresponsive. Clicking either button has no visible effect and the task stays blocked awaiting approval. Restarting the desktop app does not resolve it; the same behavior recurs after restart.

This was observed in the ChatGPT/Codex desktop UI in Chinese while working in an SSH project. A screenshot was captured, but it is not attached here because the displayed remote file path may be sensitive.

Expected: either action should immediately resolve the pending approval and allow the task to proceed or stop accordingly.

alan-iwashita · 24 days ago

Could an OpenAI maintainer please provide a status update on this issue?

I have repeatedly encountered the same failure in the Codex desktop app with a Remote SSH Linux workspace: both Allow once and Deny are unresponsive for file-edit approvals, and the task remains permanently stuck in waitingOnApproval. This reproduced multiple times in late July 2026, including after restarting/retrying, and the only reliable recovery was to terminate/archive the affected task.

Because either approval choice can leave the task unusable, this is more than a cosmetic UI problem. Is a fix assigned or targeted for a particular app release? If not, is there an officially supported workaround that preserves approval controls without switching to full access?

Aqualie · 24 days ago

This only happens when sub-agents are forked and are triggering approval flows. The workaround is to open the summary pane, click into every subagents summary and it will clear the approval/denial window. You will then need to enter any comment and force-steer the conversation. After which the approval window will appear again and you can then either approve or deny. Very annoying bug.

mengzhisy · 23 days ago

I can reproduce this on a newer Windows desktop build, and the logs match the renderer ownership/routing race described above.

Environment

  • Windows ChatGPT/Codex app: 26.730.7989.0
  • Remote environment: Ubuntu 24.04 WSL2 via Desktop Remote SSH
  • Remote Codex CLI/app-server: 0.146.0
  • Approval type: built-in file edit

Both Allow once and Deny appear clickable but do not resolve the approval. The task remains blocked in the approval dialog.

The desktop log recorded Failed to forward file approval decision with errorMessage=no-client-found six times on 2026-08-05:

02:35:12.654Z
02:35:53.022Z
02:37:16.425Z
02:37:32.629Z
02:40:43.080Z
02:42:38.397Z

A sanitized sequence around one click:

2026-08-05T02:40:38.656Z ... rendererWindowAppearance=avatarOverlay ... role=owner
2026-08-05T02:40:38.686Z ... rendererWindowAppearance=primary ... role=follower
2026-08-05T02:40:43.080Z error ... Failed to forward file approval decision ... errorMessage=no-client-found ... rendererWindowAppearance=primary

The Remote SSH connection itself remained healthy and other app-server requests continued to succeed, so this appears specific to routing the file approval decision from the visible primary renderer after ownership moved to the hidden overlay renderer.

Restarting/reconnecting does not reliably recover the pending approval. The available workaround is to resume the same thread in the remote Codex CLI and accept the pending file edit there, after which the desktop app can synchronize and continue.

This completely blocks long-running Remote SSH tasks whenever a file-edit approval is required. Please prioritize a fix or provide an officially supported recovery path that preserves approval controls.

RyanHHR · 23 days ago

I can reproduce the same core issue on a newer version.

Environment

  • Codex Desktop: 26.730.61639
  • Windows 11 25H2
  • OS build: 26200.8655
  • Remote OS: Ubuntu 24.04.4 LTS
  • Remote kernel: Linux 7.0.0-28-generic
  • Remote Codex CLI: codex-cli 0.146.0
  • Connection method: Codex Desktop built-in Remote SSH

Additional behavior

In my case, Codex first reported:

Text file busy

It then displayed a file-edit approval prompt.

Neither Allow once nor Reject works. Restarting Codex Desktop and reopening the same conversation restores the same pending approval card, and it remains unresponsive.

The conversation was created and used directly from the Windows Codex Desktop Remote SSH project, rather than being created in the CLI first.

The repository was not modified:

git status --short produced no output.

A redacted screenshot is attached.

<img width="1689" height="931" alt="Image" src="https://github.com/user-attachments/assets/8e7261bc-d7be-42a2-85b2-b7732a322432" />

RyanHHR · 23 days ago

Further confirmation after resuming the affected conversation in Codex CLI:

  • The CLI and Windows Desktop app remain synchronized normally.
  • Messages, progress, and results produced in the CLI immediately appear in the Desktop app.
  • Approving a pending edit in the CLI immediately unblocks the Desktop app.
  • However, every subsequent new file-edit approval shown in the Windows Desktop app is still unresponsive.
  • All new approval decisions must also be handled from the CLI.

This confirms that session synchronization and backend approval processing are working. The failure appears isolated to submitting file-edit approval decisions from the Windows Desktop UI in a Remote SSH conversation.

Environment:

  • Codex Desktop: 26.730.61639
  • Remote Codex CLI: 0.146.0
  • Windows 11 25H2, build 26200.8655
  • Remote Ubuntu 24.04.4 LTS
Z3usser · 20 days ago

I can reproduce this issue on macOS using the Codex desktop app with a Remote SSH workspace.
When Codex displays the file-edit permission prompt:
“Allow ChatGPT to edit the following file?”
both Allow once and Deny can become completely unresponsive. Clicking them does nothing and the conversation remains stuck waiting for approval.
Quitting and reopening the desktop app sometimes allows the pending approval to proceed, but the problem recurs. On one occurrence, the underlying authorized file edit had already been applied before the frozen UI was recovered, leaving the task partially completed even though the approval dialog appeared stuck.
This has now occurred repeatedly across separate Codex sessions.
Environment:
macOS
ChatGPT/Codex desktop app
Remote SSH workspace
ChatGPT Plus
Observed August 7, 2026
I am not attaching screenshots because the affected workspace contains confidential project information, but the visible behaviour matches this issue closely.
Expected behaviour: clicking Allow once or Deny should immediately resolve the pending file-edit approval.
Actual behaviour: both controls intermittently become completely non-responsive.

No-54 · 11 days ago

I can still reproduce this issue on the latest Windows app available to me, version 26.810.52044.

Remote host: Ubuntu 26.04 LTS, Codex CLI 0.147.0, connected via Remote SSH.
The approval dialog appears, but Allow once, Deny, Enter, and Esc are all unresponsive. I reproduced it in three different threads, including after fully quitting and restarting the app.
The same project and approval flow work normally through Codex CLI.

maybejeb · 11 days ago

Also reproducible with macOS → Linux Remote SSH, including Mac-started threads and nested Code Mode approvals

I am seeing the same failure class with the Codex macOS app connected to a Linux host through the app’s SSH remote connection.

Environment

  • Controller: Codex App on macOS
  • Codex App version:

Powered by Codex & OWL
Version 26.803.61601
Released Aug 8, 2026

  • Remote host: Linux x86_64
  • Remote Codex CLI: 0.147.0
  • Remote app-server: 0.147.0
  • Model: GPT-5.6
  • Approval mode: user approval / on request
  • The Mac app and remote CLI are signed into the same account and workspace

Observed behavior

The problem is intermittent:

  1. Several approvals can work normally.
  2. A later approval appears in the Mac app.
  3. Clicking Approve in the Mac app does nothing.
  4. The approval dialog remains visible and the turn remains blocked.
  5. The same pending approval is visible and actionable from a CLI frontend.
  6. Approving it from the CLI immediately allows the operation and turn to continue.

This occurs in both directions:

  • A conversation is started from the remote Linux CLI and subsequently appears in the Mac app.
  • A conversation is started directly from the Mac app against the Linux SSH environment.

The second case is particularly problematic because there is ordinarily no existing CLI window available to approve the request.

Strongest captured example: nested Code Mode approval

The clearest captured failure involved a nested Code Mode tool call:

outer functions.exec
  └─ inner approval-requiring apply_patch

The outer functions.exec call remained alive for approximately 193.6 seconds while waiting for the inner approval.

The Mac app displayed the approval request, but pressing the approval button did not resolve it. The rollout subsequently ended that turn while the nested tool call was still pending.

Read-only tool calls immediately before this completed normally. This was therefore not a general SSH, process execution, filesystem, or connectivity failure.

Verified CLI recovery

For a Mac-started test conversation owned by the remote app-server, an ordinary command such as:

codex resume <thread-id>

cannot attach because the app-server correctly owns the thread’s writer lock.

However, attaching another frontend to the existing app-server works:

codex --remote unix:// resume --all

After selecting the affected Mac-owned thread:

  1. The CLI displayed the pending nested approval.
  2. The approval was accepted from the CLI.
  3. The approved read-only command ran successfully.
  4. Its output returned through the nested call.
  5. The Mac-owned conversation completed normally.
  6. No lock file, SQLite database, or session file needed to be deleted or edited.

The controlled test used a read-only command:

/usr/bin/stat -c 'nested-fallback-test:%U:%G:%a:%n' /etc/passwd

The result returned successfully:

nested-fallback-test:root:root:644:/etc/passwd

This demonstrates that:

  • the backend approval request was still live;
  • the app-server could still process the decision;
  • the command execution path was functional;
  • the thread writer lock was functioning correctly; and
  • the failure was specifically in the Desktop approval UI or the routing/correlation of the Desktop approval response.

App-server restart result

A stale app-server was initially found and restarted. This released an unrelated stale writer lock and removed stale configuration state.

Afterward, ordinary approvals worked again, but that does not establish that the intermittent approval problem is fixed: this issue has historically occurred only after several approvals have already succeeded.

The original failure also occurred after earlier approvals in the same conversation had worked.

Expected behavior

When the Desktop app displays an approval request, pressing Approve should submit a decision for the exact:

  • approvalId
  • threadId
  • turnId
  • tool/item ID
  • remote app-server connection

If the approval is nested inside an outer Code Mode functions.exec call, the decision must still reach the inner tool request.

If another attached frontend resolves the request, the Mac app should receive that state update and dismiss any stale approval dialog.

Reconnect or approval replay should not leave an obsolete dialog covering a newer pending request.

Actual behavior

The Desktop app sometimes displays an approval dialog whose buttons are responsive visually but do not resolve the backend request.

The same still-live approval can be resolved immediately from a CLI connected directly to the existing app-server:

codex --remote unix:// resume --all

Related issues

This appears related to several existing approval-state and nested-tool reports:

  • #34652 — Desktop Remote SSH approval buttons are unresponsive while CLI approval works
  • #10760 — approval UI deadlock involving multiple/parallel approval-requiring tool calls
  • #21982 — approval requests not being surfaced correctly through app-server
  • #32848 — Code Mode outer functions.exec / inner exec_command approval propagation

The additional scope demonstrated here is:

  • macOS Desktop as the controller;
  • Linux as the Remote SSH host;
  • conversations started from either the Mac app or remote CLI;
  • Code Mode nested approvals;
  • remote app-server version 0.147.0; and
  • a verified non-destructive CLI recovery path.

No connector configuration, lock files, rollout files, or SQLite databases were modified during this approval test.

No-54 · 11 days ago

@maybejeb Thanks for the detailed recovery notes. I reproduced the same --remote unix:// recovery path on Windows 11 → Ubuntu Remote SSH.

Environment:

  • Windows ChatGPT/Codex app: 26.810.52044
  • Remote host: Ubuntu 26.04 LTS
  • Remote Codex CLI: 0.147.0

A few additional observations from my testing:

  • I reproduced the initial approval deadlock in four newly created Remote SSH threads.
  • In the affected thread, the Desktop approval dialog was unresponsive, while the same pending approval was immediately visible through:

``console
codex --remote unix:// resume --all
``

  • Approving from the CLI immediately advanced the Windows Desktop thread.
  • Clearing only the first pending approval was not always sufficient: another approval in the same turn could still remain unresponsive in Desktop and also had to be resolved from the CLI.
  • After the currently stuck approvals for that thread were cleared through the CLI, subsequent new approval requests in that same thread became actionable from the Windows Desktop UI again.
  • This recovery appeared to be thread-specific. Other Remote SSH threads that were already stuck remained stuck until their own pending approvals were resolved through the CLI.
  • Once a thread was recovered, Windows approval notifications also appeared again and could successfully resolve pending approvals.

So in my environment the behavior looks less like a global app-server failure and more like a per-thread approval state / routing / correlation problem. The pending backend approval remains live and actionable; the Desktop response path is what appears to become stuck.