[Windows][dot] Local task is not associated with an existing project despite matching working directory #49646

What version of the Codex App are you using (From “About Codex” dialog)?

Exact version not captured. Observed on September 30, 2026.

What subscription do you have?

Not included in this report.

What platform is your computer?

Windows desktop, connected and authorized for tasks from dot. Exact OS build not captured.

What issue are you seeing?

A task created by dot on the connected computer is not associated with the intended existing local project in the desktop UI, even when its requested working directory is explicitly set to that project's existing absolute folder.

There is also no usable "Move to project" recovery path for the affected task. This prevents organizing dot-created work alongside ordinary local tasks for the same project.

An earlier attempt omitted the working directory and therefore does not establish a product bug. The relevant attempt explicitly supplied the correct existing project directory and still appeared outside the project. Both attempts were subsequently paused.

What steps can reproduce the bug?

Observed workflow on one installation, not yet a clean-install or cross-version reproduction. The name and path below are placeholders.

1. Have an existing local project, such as ExampleProject, registered for C:\Projects\example.
2. Keep the Windows desktop connected and authorized for dot tasks.
3. Ask dot to create a task on that computer using the existing project's absolute directory as the working directory.
4. Inspect the resulting task in the desktop UI.
5. Check whether the task appears under ExampleProject and whether it can be moved there.

Actual result: the task exists but is not associated with the intended local project, and moving it into that project is unavailable.

What is the expected behavior?

A dot-created task targeting a directory already registered as a local project should be associated with that project, or creation should support explicit project selection.

If automatic association is not intended, the UI should offer a supported way to move the task into the existing local project and explain any restriction.

Additional information

A separate read-only investigation of the installed client reported the following diagnostic leads. They were not independently reverified while preparing this issue:

• The affected task had no project ID association in the inspected local state.
• Its workspace path included a cloud-workspace prefix around the Windows path, which did not match the local project path comparator.
• Tasks classified as durable did not receive the same move-to-project behavior as ordinary local tasks.
• Ordinary project-scoped task creation stored additional project association metadata.

These are investigation leads, not a confirmed end-to-end root cause. It remains unclear whether the correction belongs in task creation, workspace-path normalization, client project association, or more than one component. No application-code modification was used for those reported checks.

Related but not established duplicates: #39489 concerns macOS New Chat from a Local Project, and #35826 concerns moving ordinary cloud conversations. This report concerns dot-created tasks executing on a connected computer with an explicitly selected local project directory.

No private paths, project names, account details, conversation contents, logs, screenshots, or identifiers are included.