Skip to content

Dot creates Codex tasks with mixed Linux/Windows working paths, causing follow-up turns to fail #49753

Open

Description

@qo4u60418-max

環境

  • Windows desktop
  • ChatGPT/Codex App 26.928.21956
  • Build 12404
  • Production channel
  • App reports up to date
  • dot 已獲准連接本機 Windows 電腦
    問題 A:dot 建立的本機 Codex 任務實際成為 durable 任務,並產生混合平台工作路徑
    我要求 dot 在已連線的 Windows 電腦上建立本機 Codex 任務。任務第一次可以執行,但建立紀錄顯示:
    Task 1:
  • Thread ID:01a0f388-52de-7485-a5ba-3266b823601c
  • Host:durable
  • CWD:/tmp/codex-cloud-agent-7f3d6c255465-c8840b78ec5e4767ba6246190a0a4bd8/app_servers/thread_service/workspace/C:\Users\user\Documents\Codex\2026-10-01\task
    Task 2:
  • Thread ID:01a0f3a9-7333-76ee-8bd3-fef2de9fd02e
  • Host:durable
  • 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 工作台
    既有工作台:
  • Thread ID:01a07917-2230-7863-aa5e-830cdf0f3333
  • Host:local
  • CWD:C:\Users\user\Documents\Codex\2026-09-07\lanyang-zhixian-daily
    要求 dot 接續這個工作台後:
  • 讀取回報:unsupported placement region 12
  • 傳送訊息回報:找不到對話
    本機 Codex App 仍能正常列出並使用這個工作台,Thread ID 也已重新確認。
    預期結果
  1. 指定已連線的 Windows 電腦建立本機任務時,任務應使用 local host 與原生 Windows CWD。
  2. 任務完成第一輪後應能正常接收後續訊息。
  3. dot 應能依官方文件接續符合條件的既有 local Codex 任務;若任務不符合資格,應顯示可理解的原因,而不是 unsupported placement region 12 或「找不到對話」。
  4. 不應將 Windows 絕對路徑拼接到 Linux workspace 路徑。
    影響
    兩個由 dot 建立的任務都無法可靠地開始下一輪對話;現有工作成果仍可閱讀,但任務實際上無法繼續使用。
Image

Activity

  1. added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    app-serverIssues involving app server protocol or interfaces
    on Sep 30, 2026
  2. github-actions commented on Sep 30, 2026

    @github-actions
    Contributor

    English translation:

    Environment

    • Windows desktop
    • ChatGPT/Codex App 26.928.21956
    • Build 12404
    • Production channel
    • App reports up to date
    • 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:
    • Thread ID: 01a0f388-52de-7485-a5ba-3266b823601c
    • Host: durable
    • CWD: /tmp/codex-cloud-agent-7f3d6c255465-c8840b78ec5e4767ba6246190a0a4bd8/app_servers/thread_service/workspace/C:\Users\user\Documents\Codex\2026-10-01\task
      Task 2:
    • Thread ID: 01a0f3a9-7333-76ee-8bd3-fef2de9fd02e
    • Host: durable
    • 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
    1. When the connected Windows computer is specified for creating a local task, the task should use a local host and a native Windows CWD.
    2. After completing the first turn, the task should be able to receive subsequent messages normally.
    3. 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”.
    4. 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.
    Image
  3. qo4u60418-max commented on Sep 30, 2026

    @qo4u60418-max
    Author

    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.

  4. glaive77 commented on Oct 1, 2026

    @glaive77

    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.

  5. NaturalMatchaKing commented on Oct 1, 2026

    @NaturalMatchaKing

    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:

    1. dot creates a fresh local task on the connected Windows computer with an explicitly supplied absolute Windows working directory, using forward slashes.
    2. The initial task completes. A follow-up sent by dot also completes, and its reply can be read back.
    3. 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.

  6. glaive77 commented on Oct 1, 2026

    @glaive77

    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 path

    For each affected thread:

    1. The thread was failing from Codex Desktop.
    2. I changed the thread permission setting from Custom to Approve for me.
    3. I retried from Codex Desktop.
    4. 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.

  7. SplitMilky commented on Oct 2, 2026

    @SplitMilky

    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.

  8. added
    dotsIssues involving setting up ChatGPT dots or managing their ongoing work.
    on Oct 2, 2026
  9. WESLEY780 commented on Oct 2, 2026

    @WESLEY780

    改变权限自定义为帮我批准开会解决这个问题

  10. orangehadou commented on Oct 2, 2026

    @orangehadou

    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:

    1. A task created by dot runs initially and returns results.
    2. In the desktop app, it appears as Work, with a cloud icon and the local project folder in its tooltip.
    3. Opening that task and submitting a human follow-up fails before the next turn starts:

    invalid turn/start params: AbsolutePathBuf deserialized without a base path

    Observed thread metadata, with identifiers and the project name redacted:

    hostId: durable
    cwd: /tmp/codex-cloud-agent-<redacted>/app_servers/thread_service/workspace/E:\<local-project>
    

    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.

    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.

  11. mtmkz commented on Oct 2, 2026

    @mtmkz

    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:

    1. Have a dot create a task on the connected Windows computer.
    2. Open that task in the desktop app.
    3. Type a follow-up message and send it.
    4. 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.

  12. SevxLabs commented on Oct 2, 2026

    @SevxLabs

    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.

  13. studio-beam commented on Oct 7, 2026

    @studio-beam

    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.

  14. qo4u60418-max commented on Oct 10, 2026

    @qo4u60418-max
    Author

    補充回報(2026-10-10):原對話再次從側欄與搜尋消失,但 dot 仍能透過相同 ID 傳訊並收到新回覆。
    本 issue 原先回報兩個由 dot 建立的 Codex 對話,在使用者直接送訊息時出現:
    invalid turn/start params: AbsolutePathBuf deserialized without a base path
    現在同兩個原對話又出現使用者入口不可見的情況。它們先前曾恢復側欄顯示,目前再次消失;尚未確認這次問題是否與原始錯誤同源。
    受影響的原對話:

    1. 點點:01a0f388-52de-7485-a5ba-3266b823601c
    2. 幼成弦|阿弦:01a0f3a9-7333-76ee-8bd3-fef2de9fd02e
      兩個對話都已改名,目前名稱不含舊標題 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 與完整歷史,不要以新建對話取代。謝謝。
  15. qo4u60418-max commented on Oct 10, 2026

    @qo4u60418-max
    Author

    新發現:同時查看網頁版與 Windows 桌面 App,兩個受影響對話出現在網頁版的最近項目中,但桌面版仍不可見。尚未測試網頁端開啟及手動傳訊。

    後續測試:我與 dot 已確認網頁端可開啟受影響對話並直接交流。另外,網頁對話具有存取權設定,且在我要求下成功讀取已連線 Windows 電腦的 D:<專案> 內容。因此問題並非對話只能由 dot 操作,至少對話可從網頁端直接互動並存取本機檔案;Windows 桌面端的側欄/搜尋入口仍缺失。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingdotsIssues involving setting up ChatGPT dots or managing their ongoing work.windows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions