[Windows app 26.903.8094.0] Authorized cloudflared restoration rejected with opaque 'blocked by policy'

Problem

On 2026-09-10, Codex Desktop for Windows rejected an explicitly user-authorized attempt to restore an existing Cloudflare Tunnel for a Kakao chatbot before the requested PowerShell command executed.

The abbreviated tool error was:

exec_command failed: CreateProcess ... Rejected ... rejected: blocked by policy

The tool response did not identify the denying policy/rule, a detailed reason, or an actionable approval/remediation step. After the user explicitly confirmed restoration in chat, one retry through the same execution tool was also rejected before execution.

Environment

• Windows, PowerShell.
• Installed app package: OpenAI.Codex 26.903.8094.0, checked using Get-AppxPackage.
• Separately queried installed executable: codex-cli 0.153.4; this is not asserted to identify every app-side component.
• The affected task reported unrestricted filesystem access (danger-full-access) and approval_policy=never.
• The existing local service is FastAPI/Uvicorn bound to loopback.

Observed operation

The submitted command used PowerShell Start-Process with the already installed cloudflared.exe, a hidden window, log redirection, and arguments for tunnel --no-autoupdate --url http://127.0.0.1:<port>. It would restore an HTTPS route to the existing chatbot endpoint. This is an external tunnel launch, distinct from the local-only API launch described in #41779; a common root cause has not been established.

The public application preserves its existing API-key and employee authorization checks. Administrative routes return 404 on this entry point. No new credentials or permissions were being created. The user authorized restoration of the existing integration and updating its configured URL.

These are observations from the affected task, not a clean-project or deterministic minimal reproduction.

Checks and impact

• Ordinary PowerShell commands and local HTTP checks work.
• The local bot health endpoint returns HTTP 200.
• At the time of the tool denial, no cloudflared process was running and the previously configured tunnel address was unreachable.
• Kakao's administrator console records skill-server network connection error 1005.
• The inspected user config did not contain an explanatory permission setting; the user rules directory was absent. This does not exclude managed or service-side controls.
• The inspected local app/core logs did not reveal a more specific denial reason.
• No alternative execution tool, shell, scheduled task, or permission weakening was used to get around the rejection.
• The external integration was disconnected at the time of the report; see the manual recovery update below.

Requested clarification

Please identify the enforcing component and provide a supported resolution or an actionable explanation if this operation is intentionally restricted. The current generic rejection makes it difficult to distinguish an intentional restriction from a false positive.

The current slash-command documentation describes /approve as allowing one retry after an automatic-review denial. Follow-up on 2026-09-10: the user typed /approve into the affected app's composer. The command picker displayed 커맨드 없음 (No commands), and the visible permission selector showed 전체 액세스 (Full access). No approval item was available, so no command-level approval was granted and the rejected tunnel launch was not retried. This is a direct UI observation, not a diagnosis of why the command is unavailable. Does /approve apply to this type of rejection in this app build, and what supported approval or remediation path is available here?

Related symptom: #41779. No claim is made that its underlying cause or other commenters' workarounds apply here.

This report intentionally omits credentials, company content, contact information, real local paths, public tunnel URLs, session identifiers, and raw logs.

Manual recovery update (2026-09-10)

The user later launched the existing cloudflared executable directly in their own PowerShell window. It registered a tunnel successfully. Public HTTPS health and authenticated chatbot requests now return HTTP 200; requests without the existing API key return 401 and administrative routes remain 404. The existing Kakao bot's skill URL was updated, its administrator simulator returned the expected menu, and the skill was deployed to the existing operating bot.

The agent did not launch the tunnel through an alternative execution tool or weaken permissions. This manual recovery does not explain or resolve the original agent-side denial, and no supported in-app approval path has been established. No application reinstall was needed for this observed manual recovery. Confirmation of receipt in the user's actual KakaoTalk app is pending. Please keep investigating the opaque agent-side rejection.

Start at the Windows exec_command path that rejects the PowerShell Start-Process invocation, then trace how policy denials and the /approve command are handled. The payload names no source file or test; completion means identifying the enforcing component and providing an actionable reason and supported remediation path for this rejection.