Windows Codex app: file-edit approval buttons are unresponsive in Remote SSH conversations, while CLI approval works
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
- Sign in to Codex CLI and the Windows ChatGPT/Codex app using the
same ChatGPT Plus account.
- Connect the Windows app to a Remote SSH environment.
- Start a new conversation from Codex CLI in the remote workspace.
- Open the synchronized conversation in the Windows app.
- Ask Codex to run one harmless shell command and then create one
Markdown file using the built-in file-edit action.
- Approve the shell command in the Windows app. This works normally.
- Wait for the file-edit approval dialog.
- Click Allow once. Nothing happens.
- Click Deny. Nothing happens.
- Switch to the same synchronized conversation in Codex CLI.
- Press
yto accept the pending file edit. - The edit succeeds immediately and the Windows app synchronizes
and continues normally.
11 Comments
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
26.721.410590.145.0on-request, reviewer:userImportant 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-serverprocess tree and fully quitting/restarting Desktop did not fix the issue.Reproduction and log sequence
For a harmless
apply_patchfile-create approval after a clean Desktop restart:The thread remains in
waitingOnApproval, and the proposed test file is not created.I also removed
selected-avatar-idfrom the local Desktop config and restarted the app. That disables the visible pet, but the hiddenavatarOverlayrenderer 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.
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.
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?
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.
I can reproduce this on a newer Windows desktop build, and the logs match the renderer ownership/routing race described above.
Environment
26.730.7989.00.146.0Both 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 decisionwitherrorMessage=no-client-foundsix times on 2026-08-05:A sanitized sequence around one click:
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.
I can reproduce the same core issue on a newer version.
Environment
Additional behavior
In my case, Codex first reported:
Text file busyIt 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 --shortproduced 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" />
Further confirmation after resuming the affected conversation in Codex 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:
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.
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.
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
Powered by Codex & OWL
Version 26.803.61601
Released Aug 8, 2026
0.147.00.147.0Observed behavior
The problem is intermittent:
This occurs in both directions:
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:
The outer
functions.execcall 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:
cannot attach because the app-server correctly owns the thread’s writer lock.
However, attaching another frontend to the existing app-server works:
After selecting the affected Mac-owned thread:
The controlled test used a read-only command:
The result returned successfully:
This demonstrates that:
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:
approvalIdthreadIdturnIdIf the approval is nested inside an outer Code Mode
functions.execcall, 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:
Related issues
This appears related to several existing approval-state and nested-tool reports:
functions.exec/ innerexec_commandapproval propagationThe additional scope demonstrated here is:
0.147.0; andNo connector configuration, lock files, rollout files, or SQLite databases were modified during this approval test.
@maybejeb Thanks for the detailed recovery notes. I reproduced the same
--remote unix://recovery path on Windows 11 → Ubuntu Remote SSH.Environment:
A few additional observations from my testing:
``
console
``codex --remote unix:// resume --all
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.