You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Dot creates Codex tasks with mixed Linux/Windows working paths, causing follow-up turns to fail #49753
CWD:/tmp/codex-cloud-agent-7f3d6c255465-a42fbc0928f0422992c1a50ab42a165a/app_servers/thread_service/workspace/D:\★月殤2026
兩者皆把 Windows 絕對路徑接在 Linux 暫存路徑之後。
當我在 Task 1 傳送第二輪訊息時,訊息無法送出並顯示:
invalid turn/start params: AbsolutePathBuf deserialized without a base path
問題 B:dot 無法接續既有的 local Codex 工作台
既有工作台:
dot has been authorized to connect to the local Windows computer
Issue A: Local Codex tasks created by dot actually become durable tasks and produce mixed-platform working paths
I asked dot to create local Codex tasks on the connected Windows computer. The tasks can run for the first turn, but the creation records show:
Task 1:
CWD: /tmp/codex-cloud-agent-7f3d6c255465-a42fbc0928f0422992c1a50ab42a165a/app_servers/thread_service/workspace/D:\★月殤2026
Both append a Windows absolute path to a Linux temporary path.
When I send a second-turn message in Task 1, the message cannot be sent, and the following is displayed:
invalid turn/start params: AbsolutePathBuf deserialized without a base path
Issue B: dot cannot resume an existing local Codex workbench
Existing workbench:
Thread ID: 01a07917-2230-7863-aa5e-830cdf0f3333
Host: local
CWD: C:\Users\user\Documents\Codex\2026-09-07\lanyang-zhixian-daily
After asking dot to resume this workbench:
Reading it reports: unsupported placement region 12
Sending a message reports: Conversation not found
The local Codex App can still list and use this workbench normally, and the Thread ID has also been reconfirmed.
Expected results
When the connected Windows computer is specified for creating a local task, the task should use a local host and a native Windows CWD.
After completing the first turn, the task should be able to receive subsequent messages normally.
dot should be able to resume eligible existing local Codex tasks according to the official documentation; if a task is ineligible, it should display an understandable reason instead of unsupported placement region 12 or “Conversation not found”.
Windows absolute paths should not be concatenated onto Linux workspace paths.
Impact
Neither of the two tasks created by dot can reliably start the next turn of conversation; the existing work can still be read, but the tasks are effectively unusable for further work.
Thanks for identifying the related reports. #49488 appears to match Issue A closely: dot-created durable tasks on Windows receive a mixed Linux/Windows CWD and fail on the next turn/start with the same AbsolutePathBuf deserialized without a base path error. #49746 appears to match Issue B: dot cannot read an existing local Codex thread because of an unsupported placement region. That report observed region 8; this reproduction returns region 12, followed by “Conversation not found” when sending.
This issue reproduces both symptoms together on the newer production build 26.928.21956 / build 12404, in 2 out of 2 dot-created tasks. I will leave it open for maintainers to link or consolidate as appropriate.
I am also encountering this on Windows. Dot-created Codex tasks ran initially, but my follow-up messages fail with:
invalid turn/start params: AbsolutePathBuf deserialized without a base path
The affected tasks appear in Recents rather than under the expected project. The same tasks fail across two computers, while an existing project thread still accepts messages.
I submitted in-app feedback from an affected thread. Feedback ID: 01a0f5a6-c7bd-70bb-8107-77184ea7f01b
Dot’s available task tools do not expose host, cwd, or project-association fields, so I have not independently confirmed a mixed path in my case.
Please advise on a supported way to restore follow-up messaging while preserving existing task history and work.
Additional reproduction on Windows 10, build 19045, observed October 1, 2026. Desktop package 26.928.3736.0 and engine 0.159.3 are user-reported; those version values have not yet been independently verified.
Observed sequence:
dot creates a fresh local task on the connected Windows computer with an explicitly supplied absolute Windows working directory, using forward slashes.
The initial task completes. A follow-up sent by dot also completes, and its reply can be read back.
The owner opens the same task in Codex Desktop and tries to send a message manually. The UI shows "Error submitting message" followed by:
invalid turn/start params: AbsolutePathBuf deserialized without a base path
Expected: the owner can continue the task from the Desktop UI after dot's successful turns.
The additional distinction here is that a dot-sent follow-up succeeds while the owner's Desktop UI reply fails on the same fresh task. The failing UI request payload has not been captured, so the offending path field and any mixed-path root cause remain unconfirmed. Please investigate the difference between these two submission routes and provide a supported recovery that preserves the existing task.
No private paths, project names, task identifiers, conversation contents, screenshots, or raw logs are included.
I tested two separate Dot/HAL-created Codex threads that had previously failed with:
invalid turn/start params: AbsolutePathBuf deserialized without a base path
For each affected thread:
The thread was failing from Codex Desktop.
I changed the thread permission setting from Custom to Approve for me.
I retried from Codex Desktop.
The follow-up succeeded immediately.
I then repeated the same test on a second previously failing Dot-created thread, and it also succeeded after the same permission change.
So on my setup, switching an already-affected thread from Custom to Approve for me restored Desktop follow-up messaging in 2/2 tests without recreating the task, moving the project, reinstalling the app, or changing broader permissions.
This appears consistent with the permission-profile/sandbox-policy correlation reported in #49477. I am treating this as a workaround, not a confirmed fix for the underlying bug.
Additional detail from my affected Windows task: I also get this error when sending follow-up messages from the web UI:
invalid turn/start params: AbsolutePathBuf deserialized without a base path
Removing the UNC path from the message and retrying with plain text still fails. dot can still send follow-up instructions to the same existing task, but I cannot submit my own message through the web UI. This also blocks sending a requested approval directly in the task. I haven't confirmed the underlying cause.
Update: I installed the desktop app update available to me and fully restarted the app. The same error persists. A fresh replacement task created by dot also fails when I try to submit a message. I haven't confirmed the app version number yet.
Observed desktop log fields at 2026-10-02T02:29:30.051Z:
code: -32602
failureReason: invalid_config
method: turn/start
message: invalid turn/start params: AbsolutePathBuf deserialized without a base path
At 02:29:30.153Z, the log records [Composer] submit failed with the mixed working directory above. These are selected diagnostic fields, not a full raw-log upload.
A normally opened local Work chat on the same PC is marked Run on your computer, has hostId=local and a native Windows working directory, and accepts messages. The affected project is on E:, outside the usual Documents path.
The owner could not find the affected task on web or in the mobile app's Codex view, so switching clients did not provide an alternate direct-input route. This visibility observation may be separate from the send error; sync eligibility and the mobile Work view were not established.
Expected: humans can give follow-up instructions directly to a dot-created task, as described in the assigned-work documentation.
Cloud coordination with a connected PC is supported, so hostId=durable alone is not being reported as an error. The offending request field and root cause remain unconfirmed. The Approve for me workaround reported above was not tested here; see the Full access result in the update below.
Please investigate human Desktop follow-up submission and provide a recovery that preserves the existing task history and work. Private task/cloud-instance IDs, project names, conversation contents, and screenshots have been omitted.
The owner routinely uses Full access in local sessions. The affected cloud session created by dot was set to Custom when inspected, before the owner made the workaround change. After changing that same cloud session to Full access, the owner reported that they could send a chat message successfully.
The observed recovery is Custom → Full access. This differs from the Approve for me setting in the other reproduction above. It confirms restored human message submission in this owner's environment; task completion was not separately checked. The underlying cause and the web/mobile visibility observation remain unconfirmed. Please include permission-profile handling in the investigation and provide a supported recovery for existing tasks.
Additional reproduction on Windows, October 2, 2026 (JST).
In the Windows ChatGPT desktop app, manually sending follow-up messages to dot-created tasks fails with:
invalid turn/start params: AbsolutePathBuf deserialized without a base path
This occurs with multiple existing tasks and a newly created task, and persists after updating the app. The exact app version has not been recorded.
Steps:
Have a dot create a task on the connected Windows computer.
Open that task in the desktop app.
Type a follow-up message and send it.
The error appears before the message reaches the task.
Ordinary text and /approve both fail. The dot can still send instructions to the task, but my manual messages fail. This also prevents me from submitting requested approval text.
Expected: manual follow-up messages should reach the task without this error. I have not verified whether this has the same underlying cause as the original report.
The same-task Custom → Approve for me workaround also worked in two affected tasks on our Windows installation today (package 26.930.2377.0). Direct messages failed before selection and received completed replies afterward. Forward-slash cwd creation alone did not help here.
New dot-created tasks still opened as Custom even after saved preferences showed Approve for me, so manual per-task selection remains necessary in our tests. This does not establish repaired cwd metadata or unchanged effective permissions.
Reproduced on Windows desktop 26.930.31730, build 12947, production channel. An existing durable Work conversation remains listed and readable, but native send_message_to_thread fails before execution with “invalid turn/start params: AbsolutePathBuf deserialized without a base path”. No new recipient turn appears. The same failure persisted after the user reported quitting and reopening. Please provide a supported recovery path that preserves existing conversations and history.
Activity
github-actions commentedon Sep 30, 2026
English translation:
Environment
Issue A: Local Codex tasks created by dot actually become durable tasks and produce mixed-platform working paths
I asked dot to create local Codex tasks on the connected Windows computer. The tasks can run for the first turn, but the creation records show:
Task 1:
Task 2:
Both append a Windows absolute path to a Linux temporary path.
When I send a second-turn message in Task 1, the message cannot be sent, and the following is displayed:
invalid turn/start params: AbsolutePathBuf deserialized without a base path
Issue B: dot cannot resume an existing local Codex workbench
Existing workbench:
After asking dot to resume this workbench:
The local Codex App can still list and use this workbench normally, and the Thread ID has also been reconfirmed.
Expected results
Impact
Neither of the two tasks created by dot can reliably start the next turn of conversation; the existing work can still be read, but the tasks are effectively unusable for further work.
github-actions commentedon Sep 30, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
qo4u60418-max commentedon Sep 30, 2026
Thanks for identifying the related reports.
#49488 appears to match Issue A closely: dot-created durable tasks on Windows receive a mixed Linux/Windows CWD and fail on the next turn/start with the same AbsolutePathBuf deserialized without a base path error.
#49746 appears to match Issue B: dot cannot read an existing local Codex thread because of an unsupported placement region. That report observed region 8; this reproduction returns region 12, followed by “Conversation not found” when sending.
This issue reproduces both symptoms together on the newer production build 26.928.21956 / build 12404, in 2 out of 2 dot-created tasks. I will leave it open for maintainers to link or consolidate as appropriate.
glaive77 commentedon Oct 1, 2026
I am also encountering this on Windows. Dot-created Codex tasks ran initially, but my follow-up messages fail with:
invalid turn/start params: AbsolutePathBuf deserialized without a base pathThe affected tasks appear in Recents rather than under the expected project. The same tasks fail across two computers, while an existing project thread still accepts messages.
I submitted in-app feedback from an affected thread. Feedback ID:
01a0f5a6-c7bd-70bb-8107-77184ea7f01bDot’s available task tools do not expose host, cwd, or project-association fields, so I have not independently confirmed a mixed path in my case.
Please advise on a supported way to restore follow-up messaging while preserving existing task history and work.
NaturalMatchaKing commentedon Oct 1, 2026
Additional reproduction on Windows 10, build 19045, observed October 1, 2026. Desktop package 26.928.3736.0 and engine 0.159.3 are user-reported; those version values have not yet been independently verified.
Observed sequence:
invalid turn/start params: AbsolutePathBuf deserialized without a base pathExpected: the owner can continue the task from the Desktop UI after dot's successful turns.
The additional distinction here is that a dot-sent follow-up succeeds while the owner's Desktop UI reply fails on the same fresh task. The failing UI request payload has not been captured, so the offending path field and any mixed-path root cause remain unconfirmed. Please investigate the difference between these two submission routes and provide a supported recovery that preserves the existing task.
No private paths, project names, task identifiers, conversation contents, screenshots, or raw logs are included.
glaive77 commentedon Oct 1, 2026
Confirmed workaround on my Windows setup.
I tested two separate Dot/HAL-created Codex threads that had previously failed with:
invalid turn/start params: AbsolutePathBuf deserialized without a base pathFor each affected thread:
CustomtoApprove for me.I then repeated the same test on a second previously failing Dot-created thread, and it also succeeded after the same permission change.
So on my setup, switching an already-affected thread from Custom to Approve for me restored Desktop follow-up messaging in 2/2 tests without recreating the task, moving the project, reinstalling the app, or changing broader permissions.
This appears consistent with the permission-profile/sandbox-policy correlation reported in #49477. I am treating this as a workaround, not a confirmed fix for the underlying bug.
SplitMilky commentedon Oct 2, 2026
Additional detail from my affected Windows task: I also get this error when sending follow-up messages from the web UI:
invalid turn/start params: AbsolutePathBuf deserialized without a base path
Removing the UNC path from the message and retrying with plain text still fails. dot can still send follow-up instructions to the same existing task, but I cannot submit my own message through the web UI. This also blocks sending a requested approval directly in the task. I haven't confirmed the underlying cause.
Update: I installed the desktop app update available to me and fully restarted the app. The same error persists. A fresh replacement task created by dot also fails when I try to submit a message. I haven't confirmed the app version number yet.
WESLEY780 commentedon Oct 2, 2026
改变权限自定义为帮我批准开会解决这个问题
orangehadou commentedon Oct 2, 2026
Additional reproduction of the human follow-up failure on Windows 11 Pro x64 (build 26200), observed 2026-10-02.
Installed Windows package: OpenAI.Codex 26.928.4866.0 (verified package version; the About-dialog build was not collected).
Observed sequence:
invalid turn/start params: AbsolutePathBuf deserialized without a base pathObserved thread metadata, with identifiers and the project name redacted:
Observed desktop log fields at 2026-10-02T02:29:30.051Z:
-32602invalid_configturn/startinvalid turn/start params: AbsolutePathBuf deserialized without a base pathAt 02:29:30.153Z, the log records
[Composer] submit failedwith the mixed working directory above. These are selected diagnostic fields, not a full raw-log upload.A normally opened local Work chat on the same PC is marked Run on your computer, has
hostId=localand a native Windows working directory, and accepts messages. The affected project is on E:, outside the usual Documents path.The owner could not find the affected task on web or in the mobile app's Codex view, so switching clients did not provide an alternate direct-input route. This visibility observation may be separate from the send error; sync eligibility and the mobile Work view were not established.
Expected: humans can give follow-up instructions directly to a dot-created task, as described in the assigned-work documentation.
Cloud coordination with a connected PC is supported, so
hostId=durablealone is not being reported as an error. The offending request field and root cause remain unconfirmed. TheApprove for meworkaround reported above was not tested here; see theFull accessresult in the update below.Please investigate human Desktop follow-up submission and provide a recovery that preserves the existing task history and work. Private task/cloud-instance IDs, project names, conversation contents, and screenshots have been omitted.
Update: owner-confirmed submission workaround (2026-10-02)
The owner routinely uses Full access in local sessions. The affected cloud session created by dot was set to Custom when inspected, before the owner made the workaround change. After changing that same cloud session to Full access, the owner reported that they could send a chat message successfully.
The observed recovery is Custom → Full access. This differs from the Approve for me setting in the other reproduction above. It confirms restored human message submission in this owner's environment; task completion was not separately checked. The underlying cause and the web/mobile visibility observation remain unconfirmed. Please include permission-profile handling in the investigation and provide a supported recovery for existing tasks.
mtmkz commentedon Oct 2, 2026
Additional reproduction on Windows, October 2, 2026 (JST).
In the Windows ChatGPT desktop app, manually sending follow-up messages to dot-created tasks fails with:
invalid turn/start params: AbsolutePathBuf deserialized without a base path
This occurs with multiple existing tasks and a newly created task, and persists after updating the app. The exact app version has not been recorded.
Steps:
Ordinary text and /approve both fail. The dot can still send instructions to the task, but my manual messages fail. This also prevents me from submitting requested approval text.
Expected: manual follow-up messages should reach the task without this error. I have not verified whether this has the same underlying cause as the original report.
SevxLabs commentedon Oct 2, 2026
The same-task Custom → Approve for me workaround also worked in two affected tasks on our Windows installation today (package 26.930.2377.0). Direct messages failed before selection and received completed replies afterward. Forward-slash cwd creation alone did not help here.
Details and remaining limitation: #49477 (comment)
New dot-created tasks still opened as Custom even after saved preferences showed Approve for me, so manual per-task selection remains necessary in our tests. This does not establish repaired cwd metadata or unchanged effective permissions.
studio-beam commentedon Oct 7, 2026
Reproduced on Windows desktop 26.930.31730, build 12947, production channel. An existing durable Work conversation remains listed and readable, but native send_message_to_thread fails before execution with “invalid turn/start params: AbsolutePathBuf deserialized without a base path”. No new recipient turn appears. The same failure persisted after the user reported quitting and reopening. Please provide a supported recovery path that preserves existing conversations and history.
qo4u60418-max commentedon Oct 10, 2026
補充回報(2026-10-10):原對話再次從側欄與搜尋消失,但 dot 仍能透過相同 ID 傳訊並收到新回覆。
本 issue 原先回報兩個由 dot 建立的 Codex 對話,在使用者直接送訊息時出現:
invalid turn/start params: AbsolutePathBuf deserialized without a base path
現在同兩個原對話又出現使用者入口不可見的情況。它們先前曾恢復側欄顯示,目前再次消失;尚未確認這次問題是否與原始錯誤同源。
受影響的原對話:
兩個對話都已改名,目前名稱不含舊標題 dot-01/dot-02。Windows 桌面 App 的側欄看不到它們,搜尋也找不到。
2026-10-10 約 12:34–12:35(台灣時間,UTC+8),我授權 dot 向上述兩個原 ID 各傳一句招呼。據 dot 查核,兩個原對話均收到訊息並產生新回覆,新回合狀態均為 completed、error=null。這次沒有建立替代對話。
成功回覆後,我再次確認:側欄與搜尋仍找不到它們。dot 先前查核時,兩個原 ID 都列在使用中清單,封存清單為空;桌面端的本機側欄快取也仍保留兩個原 ID 與名稱,但快取本身不能證明服務端的即時狀態。
目前觀察到的是:原對話仍可透過 dot 的傳訊途徑互動,但使用者的側欄/搜尋入口缺失。這不代表已確認對話被改成 dot 專用,也不代表原始 Bug 已修復。
請協助調查桌面端的對話列舉/搜尋與 dot 直接存取之間的差異,恢復使用者直接開啟這兩個原對話的入口,並確認是否與本 issue 的原始錯誤相關。請保留原 ID 與完整歷史,不要以新建對話取代。謝謝。
qo4u60418-max commentedon Oct 10, 2026
新發現:同時查看網頁版與 Windows 桌面 App,兩個受影響對話出現在網頁版的最近項目中,但桌面版仍不可見。尚未測試網頁端開啟及手動傳訊。
後續測試:我與 dot 已確認網頁端可開啟受影響對話並直接交流。另外,網頁對話具有存取權設定,且在我要求下成功讀取已連線 Windows 電腦的 D:<專案> 內容。因此問題並非對話只能由 dot 操作,至少對話可從網頁端直接互動並存取本機檔案;Windows 桌面端的側欄/搜尋入口仍缺失。