Codex Desktop associates new local tasks with the wrong local project

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

Codex Desktop (Windows)

What subscription do you have?

Business

What platform is your computer?

"$([Environment]::OSVersion | ForEach-Object VersionString) $(if ([Environment]::Is64BitOperatingSystem) { "x64" } else { "x86" })"

What issue are you seeing?

Summary

Codex Desktop correctly accesses and works with my GitHub repository, but every new local task created for one project is automatically associated with a different local project (HELP).

This does not affect Git operations, commits, or GitHub synchronization, but it causes the local task history to be organized under the wrong project.

<img width="1243" height="939" alt="Image" src="https://github.com/user-attachments/assets/55742660-c739-4490-9e9e-dd71c015640e" />

Actual Behavior

Every new engineering task started from the zanmi-connect project creates a new local task under the HELP project instead.

The engineering work itself succeeds.

Environment
Windows 11
ChatGPT Business
Codex Desktop
GitHub Desktop
Git installed
Multiple Codex projects

Relevant projects:

HELP
zanmi-connect

GitHub repository:

ZanmiAI/zanmi-connect-your-ai-partner-06
Expected Behavior

When I create a new engineering task inside the zanmi-connect project, Codex Desktop should create the local task inside the zanmi-connect project/workspace.

Git operations succeed.

Repository verification succeeds.

Commits and pushes succeed.

The problem is only the association of local task history.

Steps to Reproduce
Create multiple local Codex projects.
Configure a GitHub repository for one project.
Open that project.
Create a new engineering task.
Observe that the new local task is created under another project (HELP) instead of the active project.

Troubleshooting Already Performed

We performed extensive troubleshooting before reporting this issue.

Verified:

✅ Git repository is correct.
✅ GitHub repository is correct.
✅ Repository Health Check passes.
✅ Commits push successfully.
✅ GitHub Desktop works normally.
✅ Lovable integration is correct.
✅ Engineering work is committed to the correct repository.

Additional troubleshooting:

Created a brand-new Codex Environment pointing to the correct repository.
Confirmed the environment points to zanmi-connect-your-ai-partner-06.
Confirmed the issue persists.

We also tested Codex Online.

Codex Online opens a cloud workspace (/workspace/...) without a configured Git remote, so it appears to use a different execution model and was not used to diagnose this Desktop issue.

What steps can reproduce the bug?

Feedback ID: no-active-thread-019f3580-84d1-7de0-b391-31153319ff7e

What is the expected behavior?

When I create a new engineering task inside the zanmi-connect project, Codex Desktop should create the local task inside the zanmi-connect project/workspace.
We performed extensive troubleshooting before reporting this issue.

Verified:

✅ Git repository is correct.
✅ GitHub repository is correct.
✅ Repository Health Check passes.
✅ Commits push successfully.
✅ GitHub Desktop works normally.
✅ Lovable integration is correct.
✅ Engineering work is committed to the correct repository.

Additional troubleshooting:

Created a brand-new Codex Environment pointing to the correct repository.
Confirmed the environment points to zanmi-connect-your-ai-partner-06.
Confirmed the issue persists.

We also tested Codex Online.

Codex Online opens a cloud workspace (/workspace/...) without a configured Git remote, so it appears to use a different execution model and was not used to diagnose this Desktop issue.

Additional information

No source code or Git history is lost.

The issue affects project organization and local engineering history.

As projects grow, it becomes difficult to identify which engineering tasks belong to which project because they are recorded under the wrong local workspace.
This appears to be a local workspace/project association issue rather than a Git or GitHub issue.

All repository operations continue to function correctly.