›_ Codex Issues
Codex Issues / #36417

[iOS Remote on Windows] Three projectless-chat cwd labels appear in Projects

Open 💬 3 comments Opened Aug 1, 2026 by pych-ky
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

26.727.4816.0

iOS Remote client version observed in the connection metadata: 1.2026.202

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

When I connect to a Windows Codex host from iOS Remote, the Projects section does not match the Projects section in the Windows Codex app.

The Windows app shows six explicitly configured local projects. iOS Remote, connected to the same host, shows those same six projects plus three additional project headings.

The labels of those three additional headings match the working-directory basenames of three existing chats that are recorded in the Windows app's local state as projectless. I did not create projects from those chats or perform an action to convert them into projects, and no corresponding project headings are shown in the Windows app.

Importantly, this does not affect every projectless chat in this environment. The local database currently contains 54 unarchived projectless threads, while only these three appear as additional Project headings in iOS Remote.

This report is intended to document the observed difference. I have not established whether the behavior originates in the iOS presentation, the Remote data exchanged with the Windows host, or path handling.

What steps can reproduce the bug?

I have not yet produced a clean reproduction from a fresh installation. The following consistently shows the state in this environment:

  1. Open the Windows Codex app and view the Projects section.
  2. Confirm that it contains six explicitly configured local projects.
  3. Connect to the same Windows host from iOS Remote.
  4. Open the iOS Remote sidebar and view the Projects section.
  5. Observe that the same six projects are present, together with three additional headings.
  6. Compare those additional labels with the cwd basenames of the host's projectless threads.

What is the expected behavior?

I expected the Projects section in iOS Remote to correspond to the explicit project classification shown by the connected Windows app, while chats started without a project would remain available as chats without adding Project headings.

Could you confirm whether iOS Remote is expected to derive additional project headings from thread working directories in this situation?

Additional information

Observed correlation with working-directory representation

The three matching threads differ from the other unarchived projectless threads in how their working directories are represented:

| Projectless thread group | Count | Stored cwd representation | Additional Project heading in iOS Remote |
| --- | ---: | --- | --- |
| Threads matching the additional headings | 3 | Two use a WSL-style /mnt/c/<redacted>/... path; one uses a mixed C:\mnt\c\<redacted>\... path | Yes |
| Other unarchived projectless threads | 51 | Windows extended-path form \\?\C:\Users\<redacted>\... | No |

The full paths, Windows user name, host name, and thread identifiers are omitted for privacy.

This is an observed correlation only. I have not established that the path representation causes the difference, but it may be relevant to how Remote classifies or groups threads by working directory.

Related issues
  • #22806 reports missing projects, different ordering, and pinned-chat/sidebar synchronization differences. I have not reproduced those symptoms.
  • #22819 reports a projectless conversation disappearing after reconnect. I have not reproduced that behavior.

This report concerns a different observation: three specific projectless-chat working-directory labels appear as additional Project headings in iOS Remote.

Diagnostics were submitted separately through Codex's feedback/upload flow used by /feedback, with this issue number included in the report.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 27 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #35972

Powered by Codex Action

pych-ky · 26 days ago

I reviewed #35972 after the automated duplicate suggestion. It appears related at the broader Mobile Remote/Desktop project-assignment level, but the observed sequence here is different:

  • In #35972, a project/task is created from Mobile Remote and a stale mobile project shell remains after the work is reorganized on Desktop.
  • In this report, the three chats already existed on the Windows host as projectless chats. They were not created as mobile projects, and no move or reconciliation action was performed.
  • Only the three projectless threads with the non-standard cwd representations described above appear as additional headings; the other 51 projectless threads do not.

Diagnostics have also been submitted through the Codex feedback upload flow with this issue number included in the report.

pych-ky · 26 days ago

Additional context that may help narrow this down:

I routinely switch the execution environment on this Windows host:

  • Windows Native for work that uses the Codex Chrome extension
  • WSL for development work

A read-only check of the local app state shows:

  • The six explicitly configured projects are stored as WSL UNC roots (\\wsl.localhost\... or \\wsl$\...). The project records contain root paths but no field identifying which runtime was active when a project was registered, and I found no duplicate registration of the same root.
  • The three headings in question are not present in local-projects or thread-project-assignments; all three remain recorded in projectless-thread-ids.
  • Their stored cwd values are the outliers described in the original report: two use /mnt/c/..., and one uses the mixed form C:\mnt\c\.... The mixed form does not resolve as a normal Windows path and appears consistent with an unnormalized cross-runtime path representation.

This makes Windows Native/WSL switching a possible trigger for the path-representation difference, not a confirmed cause. It may be useful when investigating path normalization and projectless classification across the Windows host and iOS Remote.