Repository navigation
Windows dot-delegated task: forwarded consent rejected, direct confirmation blocked by AbsolutePathBuf turn/start error #50664
Description
Summary
A Windows desktop task delegated by dot rejects an explicitly authorized external request before process creation because the user's consent is present only as forwarded/delegated evidence. The suggested direct-user confirmation path also fails with a turn/start path parsing error. Please investigate the supported authorization handoff and the broken confirmation path; this report does not request bypassing safety checks.
Observed sequence (2026-10-03)
- The user explicitly authorizes one paid request to an existing external API, identifying the endpoint, bounded data categories, purpose, original usage ledger, and per-page call limit in the parent dot conversation.
- The bounded authorization is forwarded to an existing desktop execution task.
- With effective
workspace-write/auto_review, the request is rejected before CreateProcess. The rejection explicitly says the authorization is only in untrusted delegated/tool evidence, not a trusted current user message. No process, API response, or new charge results from this attempt. - Attempting direct user input in the affected delegated task has separately returned:
invalid turn/start params: AbsolutePathBuf deserialized without a base path - The parent cannot read a newly supplied local comparison thread through the supported task reader; it returns:
unsupported placement format version 2
Comparison and important limitations
A read-only check of local project evidence confirms 17 actual external API responses, with matching persisted request/response/usage records. That execution's project records describe direct human authorization and never/full-access; the effective runtime settings and attribution to the supplied comparison thread could not be independently read. The local run also used a refreshed source baseline.
Consequently, authorization provenance, recorded approval mode, and source baseline differ. This is NOT a controlled experiment proving a single permission-inheritance defect, nor proof that forwarding consent should override the execution policy. A successful API response is also not evidence that application quality acceptance passed.
Expected behavior
Provide an explicit, usable, action-scoped consent route across dot and desktop execution tasks, or clearly explain the intended boundary. Direct user input should not fail during absolute-path deserialization. Supported task reading should either handle the thread format or expose a clear supported compatibility path.
Environment / reproduction limits
Windows host, dot parent conversation and delegated desktop task. Exact affected desktop build and Windows build were not captured for this report. The sequence above is retained observation; it was not re-executed solely to reproduce a paid request. No security settings were changed during the comparison investigation.
Related: #43675 reports a similar delegated-consent rejection on macOS. A common root cause is not established. The Windows input/parsing failure makes the proposed direct-consent recovery unusable here.
Privacy
User explicitly authorized this public sanitized report. It contains no email, account identifiers, task/turn/request IDs, private source content, local paths, credentials, or raw session logs.
Activity
github-actions commentedon Oct 3, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
flexmasterkill commentedon Oct 5, 2026
Additional impact observed October 5, 2026: I encountered the same combination in a dot-created Windows task.
I explicitly approved publishing one reviewed commit to a named private GitHub repository using a non-force push and creating a draft PR. The coordinating dot forwarded the original approval question and my answer verbatim to the existing task. The command was rejected before process creation because the forwarded approval was treated as untrusted delegated evidence. One retry with the same approval was also rejected, with no usable pending approval request or approval identifier exposed.
Direct replies to this task had already failed with: invalid turn/start params: AbsolutePathBuf deserialized without a base path.
I normally work remotely from my phone, so manual PowerShell commands do not restore the workflow. I did not encounter this issue before switching to dot-created tasks, although this is not a controlled root-cause test.
Is there a supported way for authenticated approval in the parent conversation to reach the exact action in the existing Windows task, or to surface that approval on the phone? How can direct input be repaired while preserving the task and its permission boundaries?
Related reports: #50697, #50428 and #50769. The approval failure and path error may have separate causes; exact affected client/backend versions have not been established.
lcan921207-svg commentedon Oct 6, 2026
I can reproduce the same input failure on Windows 10, Codex desktop 26.930.7945.0, CLI 0.160.1.
Direct messages to the affected task fail in both desktop and web with “invalid turn/start params: AbsolutePathBuf deserialized without a base path”. Messages from the parent dot conversation to that same task still reach it and can execute.
The actual Windows working directory exists and is readable. Task metadata appears to concatenate a Windows absolute path with a POSIX workspace path; I have not isolated the responsible field.
The desktop connection is online and authorized. DNS, TLS through the configured proxy, and WebSocket connectivity checks pass. /feedback succeeds; /approve is unavailable.
Forwarded authorization for a specific UI fix is not accepted, while direct user confirmation cannot enter the task.
What supported recovery preserves this task’s history and permissions? Which sanitized path/turn-start fields and diagnostics should I collect? I’m seeking a working, action-scoped confirmation flow under the existing safety checks.
Delfavni commentedon Oct 6, 2026
I’m also experiencing this on Windows app 26.930.4958.0 with bundled CLI 0.160.0.
Direct follow-up messages to an existing desktop-connected task fail with:
invalid turn/start params: AbsolutePathBuf deserialized without a base path
The assistant can still send messages to that same task and run permitted read-only commands. A new local chat accepted a harmless message and returned a valid Windows working directory, but that did not repair the original task. Closing the phone app did not establish a fix. Local logs recorded invalid_config / JSON-RPC -32602 during failed submissions.
This blocks the direct-user approval flow needed to continue work. Is there a supported way to repair the existing task’s path metadata without losing its history or changing security settings? I can provide task identifiers and sanitized diagnostics privately to support.
flexmasterkill commentedon Oct 6, 2026
Fresh Windows reproduction and observed workaround, October 6, 2026:
A newly created delegated task was visible in the owner's Codex app and successfully ran a harmless read-only command through delegation. With the task's permission profile displayed as Custom, the owner's direct message submission failed with:
Error submitting message
invalid turn/start params: AbsolutePathBuf deserialized without a base path
The owner then manually switched the task to Full Access and retried. The message succeeded. Readback of the task confirmed that the direct user-authored message was received and answered.
This is one observed sequence, not proof of root cause or a recommendation to broadly enable Full Access. Current app/CLI versions were not freshly verified. Task startup, sidebar visibility and direct message submission behaved differently in this case.
The distinct forwarded-approval problem in #51412 remains separate. No private task identifiers, filesystem paths, device details or project data are included.
yorten commentedon Oct 8, 2026
I’m also experiencing this exact issue. I reproduced it today, October 8, 2026, on Windows 11 using the ChatGPT desktop app, powered by Codex & OWL, version 26.1002.52244 (released October 7).
My dot created a brand-new disposable task with instructions to reply only “OK” and stop, without using tools or accessing any project files. The task successfully replied “OK” and finished.
When I opened that task in the Windows desktop app and tried to send “Reply WINDOWS OK. Do not use tools. Then stop.”, I received:
Error submitting message
invalid turn/start params: AbsolutePathBuf deserialized without a base path
This reproduces on a simple communication-only task, without running repository commands or changing project files.
Separately, the same dot-created task is visible on my Windows desktop but does not appear on my Pixel’s Android app. I don’t know whether that is related to the Windows error.
These problems prevent me from reliably using dot to supervise Codex tasks and provide approvals when needed. Is there a known fix or any additional diagnostic information that would help?
taranburns-code commentedon Oct 8, 2026
Additional Windows observations from October 8, 2026. Verified desktop package: 26.1002.7124.0, client build 13536; a retained desktop log identifies local app-server 0.162.0-alpha.2.
I explicitly approved bounded actions in my dot conversation, including a read-only capacity assessment, an official-runtime installation, and a scoped workflow repair. The parent forwarded the original request and answer to the existing executing session. The delegated handoffs were rejected because the approval was treated as untrusted forwarded transcript content. A single same-action retry with the original user evidence was also rejected in several cases. Repeating the scoped instruction directly in the local session allowed those tasks to proceed.
A different delegated task could not accept my direct message at all, displaying exactly:
invalid turn/start params: AbsolutePathBuf deserialized without a base path. Its recorded working directory combined a POSIX workspace prefix with a Windows path. This is an observation, not proof of which component caused the parsing failure. Parent-to-task messaging and direct user input behaved differently.Please provide a supported action-scoped authorization handoff and a recovery path for direct input without losing task history or weakening permissions. No denied action was rerouted to bypass review. No private task identifiers, conversation text, paths, credentials or raw logs are included here.
rmach816 commentedon Oct 20, 2026
Additional Windows reproduction, October 20, 2026. This appears related to the two existing failures described here; a common root cause has not been established.
The action transmits campaign and contact data to another agent, but the supplied transcript and planned prompt are explicitly untrusted and provide no trusted authorization in this judging context.Wrapper:This action was rejected due to unacceptable risk.No rejected request ID was exposed.invalid turn/start params: AbsolutePathBuf deserialized without a base path. The observed interval was 21:38:54–21:40:51 UTC; the exact call instant/request ID was not exposed.No denied data transfer was replayed through another actor or tool. No approval policies, permissions, credentials, saved metadata or security settings were changed. No replacement task was created and no dependent business-data mutations occurred. At the time of this initial report, exact desktop/backend versions had not been freshly verified; the appended update records the later desktop verification and notes that the cloud backend build remains unknown.
OpenAI Help Center's support chat received a redacted report but stated it could neither create an official case/reference nor connect a human from that chat. It suggested the built-in feedback flow or this official issue tracker. Please provide a supported repair for the existing relay's startup context and an action-scoped authorization path that makes the actual owner instruction available to the relevant review context, while preserving history and normal security controls.
This public follow-up is owner-authorized and intentionally omits business identity/contact information, private task/turn/user-item IDs, filesystem paths, account identifiers, assets, preview codes/links, credentials, payment data and raw session logs. Private technical references are retained locally for an appropriate support channel.
Additional code-path and build evidence, October 20, 2026:
OpenAI.Codex_26.1013.4894.0; its active app-server binary reports0.163.0-alpha.10.2. The cloud backend build is unknown. The public source reviewed is tagrust-v0.163.0.sender_context.rscaptures a bounded snapshot from the direct sender thread at delivery admission: up to three recent local user messages and preceding assistant context. It excludes inherited entries and retained verified answers.guardian_sender_messages.rsgives each rendered exchange a shared 900-byte UTF-8 limit, prioritizes the user message, omits over-budget user evidence as unavailable rather than truncating it, and labels assistant context untrusted. The fragment expressly describes partial history for that delivery, not permission transfer. A locally measured real user instruction exceeds the role-rendered limit; that predicts omission under this source rule but is not an observation of the private Guardian input.user_authorization.rsand PR #42579 show a V2 subagent Guardian can receive bounded root messages and retained verified answers. That does not establish that an independent peer-chat relay hop recursively carries the original human authorization. PR #49951 documents the sender snapshot and the reviewer-only use of its assistant context.mcp__codex_app__send_message_to_threadwith the host omitted. This alone does not show whether the omitted host or active relay state caused admission. Local desktop logs also show JSON-RPC-32602 invalid_configstartup failures; their exact timestamps and request identifiers are retained privately and omitted here. The evidence does not identify a specific failing path field or establish a permanent repair.Please clarify the smallest supported way to make an existing, genuine human instruction available to the action review for a peer-chat handoff through the same existing threads, or the normal action-scoped approval surface, while keeping agent-authored delegated text untrusted. Please also advise the supported target-native path handling for starting an existing thread on desktop. Preserve normal security and tenant boundaries; no bypass or weakening is requested.