# \[Windows Desktop 26.903.61454\] Chats created inside a Local Project appear in Recents but not under the Project

**URL:** <https://community.openai.com/t/windows-desktop-26-903-61454-chats-created-inside-a-local-project-appear-in-recents-but-not-under-the-project/1396709>\
**Category:** Bugs\
**Tags:** chatgpt, windows-app, desktop, project-folder\
**Created:** [September 11, 2026, 3:12pm UTC](https://community.openai.com/t/windows-desktop-26-903-61454-chats-created-inside-a-local-project-appear-in-recents-but-not-under-the-project/1396709 "2026-09-11T15:12:23Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![chaputy](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/chaputy/32/761898_2.png) [@chaputy](https://community.openai.com/u/chaputy)\
**Post date:** [September 11, 2026, 3:12pm UTC](https://community.openai.com/t/windows-desktop-26-903-61454-chats-created-inside-a-local-project-appear-in-recents-but-not-under-the-project/1396709/1 "2026-09-11T15:12:23Z")

</div>

## Environment

- Platform: Windows 11

- ChatGPT Desktop version: **26.903.61454**

- ChatGPT Plus

- Project type affected: **Local Project**

- Date reproduced: September 11, 2026

## Issue

When I create a new Chat from inside a Local Project in the ChatGPT Windows Desktop app, the conversation is created and works normally, but it does not appear in the list of conversations belonging to that Local Project.

Instead, the conversation appears only under **Recents**.

I have reproduced this multiple times.

The important comparison is that the same workflow works correctly with a Cloud Project: a new Chat created from inside a Cloud Project appears in that project’s conversation list as expected.

## Steps to reproduce

1. Open ChatGPT Desktop for Windows.

2. Create or open a Local Project associated with a local folder.

3. From inside that Local Project, start a new Chat.

4. Send a message and continue the conversation normally.

5. Return to the Projects view and open the Local Project.

6. Check its conversation list.

7. Check Recents.

## Expected behavior

Because the Chat was created from inside the Local Project, it should appear in that Local Project’s conversation list.

It may also appear in Recents, but the Project should retain and display the association.

## Actual behavior

The Chat appears under Recents but does not appear in the Local Project’s conversation list.

This makes it difficult to maintain a project-based workflow because conversations started specifically within a Local Project become effectively detached from the Project in the UI.

## Control test with Cloud Projects

I performed the same test using a Cloud Project:

1. Open a Cloud Project.

2. Start a new Chat from inside the Project.

3. Send a message.

4. Return to the Project.

Result: the Chat appears correctly in the Cloud Project’s conversation list.

Therefore, on the same account and Desktop application:

- Cloud Project → new Chat → displayed under Project: **YES**

- Local Project → new Chat → displayed under Project: **NO**

- Local Project Chat → displayed under Recents: **YES**

## Additional observation

Inside a Local Project I can choose between Chat and Work. In one test, I started with Chat and the task was automatically handed off to Work when appropriate. That part worked.

Work was also able to access both the Local Project’s filesystem context and my connected Google Drive during the same task.

The issue reported here is specifically the **conversation-to-Local-Project association/display in the Desktop UI** , not Work’s ability to execute the task.

## Reproducibility

Consistently reproducible on **ChatGPT Desktop 26.903.61454 for Windows**.

I have already reported the issue to OpenAI Support, but I am posting it here to determine whether other Windows Desktop users can reproduce the same Local Project behavior.

---

<div class="post-metadata">

**Author:** ![EricGT](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/ericgt/32/20571_2.png) [@EricGT](https://community.openai.com/u/EricGT)\
**Post date:** [September 11, 2026, 3:27pm UTC](https://community.openai.com/t/windows-desktop-26-903-61454-chats-created-inside-a-local-project-appear-in-recents-but-not-under-the-project/1396709/2 "2026-09-11T15:27:20Z")

</div>

Welcome to the fourm!

Since your post is not reported using the Codex category I will not take it to be for Codex.

I was interested in this so took a look at the Codex issues, this one appears similar to what you report.

> <https://github.com/openai/codex/issues/29366>
>
> \### What version of the Codex App are you using?
> 
> Codex Desktop for Windows. Obs…erved installed package path/version family:
> 
> \`\`\`text
> OpenAI.Codex\_26.616.6631.0\_x64\_\_2p2nqsd0c76g0
> \`\`\`
> 
> \### What subscription do you have?
> 
> ChatGPT Plus/Pro user. Exact account details intentionally omitted from the public issue.
> 
> \### What platform is your computer?
> 
> Windows desktop app.
> 
> \### What issue are you seeing?
> 
> Chats created directly from a saved project in the Codex Desktop sidebar do not appear under that project. The project section continues to display Italian localized text:
> 
> \`\`\`text
> Nessuna chat
> \`\`\`
> 
> which corresponds to \`No chats\`.
> 
> This is misleading because the threads are not lost and do have the correct working directory. They are returned by thread search/listing and have \`cwd\` equal to the saved project path, but the project sidebar still shows no chats.
> 
> \### Local project involved
> 
> Redacted path form:
> 
> \`\`\`text
> %USERPROFILE%\\Documents\\Codex\\2026-04-24\\browser-use-plugin-browser-use-openai
> \`\`\`
> 
> Project label:
> 
> \`\`\`text
> Laboratorio tecnico Argo - Archivio e AI locale
> \`\`\`
> 
> \### Steps to reproduce
> 
> 1. Save/add a local project in Codex Desktop.
> 2. Create a new chat from that saved project in the sidebar.
> 3. Send a message in the chat.
> 4. Return to the project section in the sidebar.
> 5. Observe that the project still shows \`Nessuna chat\` / \`No chats\`.
> 6. Restart Codex.
> 7. Reboot Windows.
> 8. Observe that the project still shows \`Nessuna chat\` / \`No chats\`.
> 
> \### Expected behavior
> 
> A chat created from a saved project should appear under that saved project in the sidebar.
> 
> If the chat has \`cwd\` equal to the saved project path, the project sidebar should not say \`No chats\`.
> 
> \### Actual behavior
> 
> The chat is visible/searchable as an autonomous/recent thread, and the runtime uses the correct project directory, but the saved project group still shows \`Nessuna chat\`.
> 
> \### Diagnostic evidence
> 
> Three affected thread IDs:
> 
> \`\`\`text
> 019eebeb-e153-7713-8a8b-005776df5d8e
> 019eebf2-0dd1-7110-ad2f-498b622cbdbd
> 019eec03-c6dc-73f2-a02e-f659d00d4d14
> \`\`\`
> 
> \`list\_projects\` returns the saved project correctly:
> 
> \`\`\`text
> projectId/path = %USERPROFILE%\\Documents\\Codex\\2026-04-24\\browser-use-plugin-browser-use-openai
> label = Laboratorio tecnico Argo - Archivio e AI locale
> \`\`\`
> 
> \`list\_threads\` returns the affected threads with:
> 
> \`\`\`text
> cwd = %USERPROFILE%\\Documents\\Codex\\2026-04-24\\browser-use-plugin-browser-use-openai
> \`\`\`
> 
> The local \`.codex-global-state.json\` initially did not contain \`thread-workspace-root-hints\` entries for the affected project threads. As a diagnostic experiment, I added entries mapping those thread IDs to the project root. The entries persisted after restart, but the project sidebar still displayed \`Nessuna chat\`.
> 
> So either the sidebar does not use \`thread-workspace-root-hints\` for this grouping, or a separate index/cache/grouping mechanism is stale or inconsistent with the underlying thread metadata.
> 
> \### Impact
> 
> This makes the project sidebar unreliable as a working-memory surface. A user can create a chat from a project and reasonably believe the chat will remain under that project, but the UI reports \`No chats\` even though the thread exists and has the correct \`cwd\`.
> 
> It creates a data-loss-class UX problem even when no data is actually lost.
> 
> \### Related issues
> 
> This appears related to the broader family of project/sidebar/thread indexing problems, including:
> 
> \- #21128
> \- #20741
> \- #27159
> \- #27843
> \- #28094
> \- #29130
> 
> I am filing this as a fresh reproducible variant because the chat was created directly from the saved project, the project path is a normal Windows local path rather than WSL, and adding \`thread-workspace-root-hints\` did not make the sidebar list the chats.
> 
> \### Requested guidance / fix
> 
> Please clarify or fix the authoritative source of truth for project-to-thread grouping in Codex Desktop.
> 
> At minimum, Codex should provide one of the following:
> 
> \- a supported way to rebuild the project/sidebar thread index from durable local state;
> \- a documented local recovery command;
> \- project sidebar grouping based directly on persisted thread \`cwd\` with proper path normalization;
> \- or a UI action to move/attach an existing thread to a saved project.
> 
> \### Note on recognition / compensation
> 
> I understand this report may not qualify for OpenAI security or safety bug bounty programs, because it appears to be a product/UI bug rather than a security vulnerability. Still, if OpenAI offers any recognition, credits, or compensation for reproducible product bugs that improve Codex reliability, I would appreciate consideration.

---

<div class="post-metadata">

**Author:** ![chaputy](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/chaputy/32/761898_2.png) [@chaputy](https://community.openai.com/u/chaputy)\
**Post date:** [September 11, 2026, 3:31pm UTC](https://community.openai.com/t/windows-desktop-26-903-61454-chats-created-inside-a-local-project-appear-in-recents-but-not-under-the-project/1396709/3 "2026-09-11T15:31:08Z")

</div>

**Update / workaround confirmed**

I found an additional behavior that may help isolate the issue.

A Chat/Work conversation created from inside a Local Project does not automatically appear under that Project and is initially visible only in Recents.

However, if I manually assign that same conversation to the Local Project afterward, it immediately appears correctly in the Project’s conversation list.

I tested this with multiple conversations, including existing Work conversations. I also completely closed and reopened the ChatGPT Desktop app. The manually assigned conversations remained correctly associated with and displayed under the Local Project after restart.

So the Local Project is able to store, persist and display the conversation association correctly.

The issue therefore appears specifically related to the **automatic project association when a new conversation is created from inside a Local Project**.

**Confirmed workaround:**

1. Create the Chat/Work conversation.

2. Find it under Recents.

3. Manually assign it to the intended Local Project.

4. The conversation appears under the Project and remains there after restarting ChatGPT Desktop.

---

<div class="post-metadata">

**Author:** ![chaputy](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/chaputy/32/761898_2.png) [@chaputy](https://community.openai.com/u/chaputy)\
**Post date:** [September 11, 2026, 3:36pm UTC](https://community.openai.com/t/windows-desktop-26-903-61454-chats-created-inside-a-local-project-appear-in-recents-but-not-under-the-project/1396709/4 "2026-09-11T15:36:48Z")

</div>

**NOTE** : these messages are being generated by ChatGPT from my conversation with it.

Thanks — yes, this GitHub issue appears to describe the same underlying problem I am seeing.

The main behavior matches exactly:

- a chat is created from inside a Local Project;

- the chat works normally and uses the expected local project context;

- it appears in Recents;

- but it is not automatically listed under the Local Project.

I also found one additional behavior that may be useful:

If I manually assign the affected chat to the Local Project afterward, it immediately appears correctly under that Project. I tested this with multiple chats, then completely closed and reopened ChatGPT Desktop, and the manually assigned chats remained correctly associated with the Project.

So in my case, persistence and project grouping work once the association is created manually. The failure appears to be specifically the automatic project association when the chat is initially created.

Environment:

- Windows 11

- ChatGPT Desktop 26.903.61454

- ChatGPT Plus

---

<div class="post-metadata">

**Author:** ![SilasN](https://avatars.discourse-cdn.com/v4/letter/s/3bc359/32.png) [@SilasN](https://community.openai.com/u/SilasN)\
**Post date:** [September 16, 2026, 1:03pm UTC](https://community.openai.com/t/windows-desktop-26-903-61454-chats-created-inside-a-local-project-appear-in-recents-but-not-under-the-project/1396709/6 "2026-09-16T13:03:12Z")

</div>

I can reproduce the same issue on macOS, but I’m seeing an additional failure mode that prevents the manual workaround described above.

**Environment**

- macOS 26.2 (25C56)
- Apple Silicon
- ChatGPT Desktop 26.908.70816
- ChatGPT Pro
- Project type: Local Project
- Reproduced Sep 16, 2026, ~13:30 BST

**Reproduction**

1. Create or open a Local Project associated with a local folder.
2. Start a new Chat from inside that Local Project.
3. Send the first message.
4. The conversation works normally, but appears under **Recents** rather than in the Local Project.

This matches the behavior reported above.

**Difference from the reported workaround**

In my case, I cannot manually assign the detached conversation back to the Local Project.

When I open **Move to project** on the conversation, the picker contains a number of my other projects, but the Local Project the conversation was originally created from is not present at all.

The Local Project itself still exists and can be opened normally from the Projects UI. It is specifically missing as a destination in the **Move to project** picker.

I also tested **Move to project** from an unrelated existing conversation, and the same Local Project is absent there as well. This suggests the issue is not specific to the detached conversation; the Local Project itself is not being surfaced as an available move destination.

**Expected behavior**

- A Chat created from inside a Local Project should remain associated with that Project.
- If the automatic association fails, that Local Project should at minimum be available as a destination under **Move to project**.

**Actual behavior**

- Local Project → new Chat → conversation appears under **Recents** only.
- **Move to project** → originating Local Project is absent.
- The same Local Project is also absent from **Move to project** for unrelated existing conversations.
- Therefore the manual workaround that works on Windows is not available in this case.

---

<div class="post-metadata">

**Author:** ![chaputy](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/chaputy/32/761898_2.png) [@chaputy](https://community.openai.com/u/chaputy)\
**Post date:** [September 16, 2026, 1:42pm UTC](https://community.openai.com/t/windows-desktop-26-903-61454-chats-created-inside-a-local-project-appear-in-recents-but-not-under-the-project/1396709/7 "2026-09-16T13:42:50Z")

</div>

Thanks @SilasN for sharing your macOS findings.

I have an additional observation from Windows that may help narrow this down: the mode selected **before sending the first message** appears to make a difference.

In my case, a new conversation opened from inside a Local Project defaults to **Chat**. I observed two different outcomes:

- **Start in Chat, then hand off to Work:** the resulting conversation appears in **Recents** , but not under the Local Project.

- **Select Work before sending the first message:** the conversation appears correctly under the Local Project.

This suggests that the Chat → Work handoff may be involved in the missing project association, although I cannot confirm the underlying cause or whether this explains every case.

For now, selecting **Work before sending the first message** has worked for me when starting a new conversation in a Local Project. This does not resolve conversations already affected.

@SilasN, does starting directly in Work make any difference on your Mac? Your finding that the Local Project is also missing from **Move to project** is an additional issue that this workaround may not address.

I’m continuing to observe the behavior and sharing this in case it helps others reproduce or avoid the issue.

---

<div class="post-metadata">

**Author:** ![Clueless](https://avatars.discourse-cdn.com/v4/letter/c/35a633/32.png) [@Clueless](https://community.openai.com/u/Clueless)\
**Post date:** [October 12, 2026, 5:47pm UTC](https://community.openai.com/t/windows-desktop-26-903-61454-chats-created-inside-a-local-project-appear-in-recents-but-not-under-the-project/1396709/8 "2026-10-12T17:47:04Z")

</div>

I’m experiencing the same issue with ChatGPT Desktop on Linux.

**Environment**

- Fedora KDE 44

- ChatGPT Desktop (Powered by Codex & OWL)

- Version `26.1007.21434` (released October 8, 2026)

I have an existing project named `llm-tooling` containing three conversations. The project and all three conversations appear correctly organized in the ChatGPT web interface.

In the desktop application, however, the same project displays **“No chats”** , while all three conversations appear separately under **Recents**.

I can open those conversations from Recents, but they’re not associated with the project in the desktop sidebar as they are in the browser.

I suspect creating a conversation through Codex mode might behave differently, but I haven’t tested that because I primarily use regular ChatGPT and don’t want to consume separate Codex usage for what should be ordinary project conversations.

The issue is consistent in my desktop application, and I can provide screenshots comparing both interfaces.

It would be helpful to know whether regular ChatGPT conversations are supposed to appear under the same project in Desktop, or whether this is an unintended distinction between desktop local projects and web projects.
