Windows Desktop: Local Projects indistinguishable from regular Projects; Chat operations fail silently

Summary
The current ChatGPT Windows desktop app displays Local Projects and regular ChatGPT Projects indistinguishably in the same Projects section of the sidebar, although they have different capabilities.
This caused a reproducible UI/UX failure when trying to move a normal Chat thread into a Local Project.
During the official feedback process I also discovered a second reproducible issue: submitting / → Feedback from the affected active Chat thread with “Include this ChatGPT conversation and diagnostic logs” enabled nevertheless produces a no-active-thread-... Feedback ID instead of the expected session ID.
Environment
ChatGPT Windows app: 26.903.71938
Release date shown by app: 2026-09-10
App About dialog: “Powered by Codex & OWL”
OS: Windows 11 Pro 25H2
OS Build: 26200.9445
Issue 1: Local Project is presented like a regular ChatGPT Project
I created a Local Project named “Patente” with a local source folder.
In the sidebar, “Patente” appears under the same “Projekte” / “Projects” heading as regular ChatGPT Projects such as Solar, Raspberry Pi, CCU, QNAP, Unifi, etc. There is no visible label, icon, badge, tooltip, or other indication that “Patente” is a fundamentally different project type.
Steps to reproduce

1. Create a Local Project with a local source folder.
2. Open a normal Chat thread. In my case this was “SmartBuilding Definition”.
3. Drag the Chat thread onto the Local Project in the sidebar.
4. Nothing happens. There is no error, warning, tooltip, or explanation.
5. Open the Chat thread menu and select Project.
6. Regular ChatGPT Projects are offered as destinations.
7. The Local Project is silently absent from the destination list, despite being displayed alongside those projects in the sidebar.
8. Open Edit Project for the Local Project.
9. Only there does the UI expose Source folders and Remove Local Project, revealing that this is a different type of project.
   Actual behavior
   The UI presents both object types as Projects without communicating their different capabilities. Unsupported operations either silently do nothing (drag and drop) or silently omit the Local Project (Project destination menu).
   Expected behavior
   Local Projects should be clearly distinguishable from regular/cloud ChatGPT Projects.
   For example:

• label them as Local in the sidebar;
• use a distinct icon/badge;
• explain incompatible drag-and-drop operations instead of silently ignoring them;
• show Local Projects disabled in incompatible destination menus with an explanation, rather than silently omitting them;
• clearly document which thread types (Chat, Work, Codex) a Local Project supports.
  This is particularly problematic in an AI-assisted UI: because the UI itself did not expose the distinction, ChatGPT repeatedly interpreted the Local Project as a regular Project and gave several incorrect UI instructions before screenshots and the Edit Project dialog revealed the distinction.
  Issue 2: In-chat Feedback fails to attach the active thread
  OpenAI Help Support instructed me to submit the above issue from the affected Chat thread using:
  / → Feedback → Bug
  with “Include this ChatGPT conversation and diagnostic logs” enabled.
  I did this twice, directly from the active “SmartBuilding Definition” Chat thread.
  Both submissions returned Feedback IDs beginning with no-active-thread:
  First submission:
  no-active-thread-01a09254-90c6-7081-9002-9082ebafc154
  Second submission:
  no-active-thread-01a09257-6fb4-7673-b392-5b184e7371de
  No separate Session ID was displayed.
  The exact German confirmation UI says:
  “Feedback gesendet”
  “Feedback gesendet. Wenn das Problem weiterhin besteht, bitte GitHub-Problem öffnen oder diese ID in einem bestehenden offenen Problem erwähnen.”
  followed by “Feedback-ID” and the no-active-thread-... identifier.
  The second submission was specifically made after OpenAI Help Support suggested that the first no-active-thread result might indicate that the active conversation had not been attached. The second attempt reproduced exactly the same behavior.
  Expected behavior
  When feedback is submitted from an active Chat thread with “Include this ChatGPT conversation and diagnostic logs” enabled, the active thread/session should be attached and the expected Session ID should be returned.
  Supporting screenshots
  I am attaching screenshots showing:

1. Local Project “Patente” displayed together with regular Projects in the sidebar.
2. The Chat → Project destination menu where regular Projects are listed but “Patente” is absent.
3. Edit Project for “Patente”, showing its source folder and “Remove Local Project”.
4. The feedback confirmation showing the no-active-thread-... Feedback ID.
5. ChatGPT Windows app version.
6. Windows version/build.
   OpenAI Help Support identified both behaviors as reproducible Windows desktop issues and directed me to report them here.

No source files or tests are named. Reproduce both behaviors in the Windows desktop app, then trace the sidebar and project-destination UI plus the in-chat feedback submission flow. Done means Local Projects are visibly distinct with clear handling of unsupported operations, and feedback from an active thread returns the expected session information.