Windows desktop: Ctrl+N from a running task opens the new-task screen in an unrelated project

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

Windows app package version: 26.901.4073.0, identified from the running desktop application's package path. Observed on September 4, 2026.

What subscription do you have?

Not specified.

What platform is your computer?

Windows 11, version 25H2, build 26200.9168, x64.

What issue are you seeing?

Pressing Ctrl+N while viewing a running task in one local project opens the new-task screen scoped to a completely different local project.

I normally use Ctrl+N to start a new task within the project of the task I am currently viewing. For my newest project (Project A), pressing it while viewing a running task instead opens the new-task start screen with an unrelated existing project (Project B) selected. The project switch is already visible before submitting any new prompt.

The same shortcut behaves normally when used from a task in another project (Project C): the new-task screen remains scoped to Project C. This makes the behavior inconsistent between projects in the same app installation.

What steps can reproduce the bug?

The following reproduces the behavior in the affected existing setup; the conditions needed to trigger it in a fresh installation are not yet known.

1. Have multiple local projects in the desktop app, including a recently added Project A and an unrelated Project B.
2. Open a running task belonging to Project A.
3. Press Ctrl+N.
4. Observe that the new-task screen is scoped to Project B instead of Project A.
5. As a comparison, open a task in Project C and press Ctrl+N. In that case, the new-task screen correctly remains scoped to Project C.

What is the expected behavior?

Ctrl+N should open a new task scoped to the project of the currently viewed task, consistently across projects. Starting a new task from Project A should preserve Project A as the selected project.

Additional information

• The source task was running when this happened. It is not yet known whether running versus idle state affects the bug.
• Project A is the most recently added project. Whether project age or registration state is relevant is unknown.
• There is also an earlier task intended for Project A that was created in Project B. Local task metadata confirms that this earlier task is associated with Project B and has Project B's working directory. I now suspect the same unexpected project switch caused that incident, but the shortcut used on that earlier occasion is uncertain, so it is not a confirmed reproduction of the Ctrl+N trigger.
• This can lead to submitting a task in an unintended working directory if the project change goes unnoticed.
• The root cause has not been established.

Related reports, with different described triggers or symptoms:

• #31213 describes new local tasks being associated with the wrong project while the engineering work still uses the intended repository. Here, the wrong project is already selected on the new-task screen, before submission.
• #42761 describes project selection changing across independent windows after sending a prompt. The observed trigger here is Ctrl+N from an existing task.

Reproduce the Ctrl+N flow with Projects A, B, and C on the Windows desktop app, comparing the selected project before and after opening a new-task screen. Inspect the local task metadata and project association for the affected tasks, then establish conditions that consistently preserve the currently viewed task's project without changing the selected project.