[Windows/Android Remote] New desktop projects/threads do not appear on mobile; original project syncs, mobile-started thread now hits trust gate

Summary

Codex Remote project/thread synchronization is asymmetric between a Windows Codex host and ChatGPT on Android.

An older/original Codex project created near the beginning of use still appears on both Windows and Android and can be used cross-device. However, later projects created in the Windows Codex app do not appear in the Android Codex Remote project list, even after starting a thread inside the project.

Historically, threads started from Android Remote did appear on the Windows host, while threads/projects started on Windows after the original project did not appear on Android.

On 2026-08-29, the behavior changed again: starting a normal new thread from Android Remote produced a project trust error referencing a newly generated local Codex directory on the Windows host. This is the first time this trust gate appeared for the previously working Android-started-thread flow.

This looks like a project/thread registration or Remote project-discovery regression rather than a general pairing failure, because the original project is still visible on both devices and Android-started threads have historically reached the Windows host.

Environment

Host: Windows Codex desktop app
Remote client: ChatGPT Android app
Android app version: 1.2026.230
Same ChatGPT account on both devices
Date observed: 2026-08-29
Exact Windows Codex desktop build not captured yet

Known-good baseline

The user's original long-running project (created early in their Codex usage) behaves correctly:

The project appears in Codex on the Windows laptop.
The same project appears in Codex Remote on Android.
This proves that the account/host pairing can expose at least one desktop project to mobile.

Broken behavior: later desktop projects

A later project (for video-generation work) was created in Codex on Windows.

Reproduction:

Open Codex on Windows.
Create/open a new project folder in the Codex app.
Start a Codex thread in that project and send a message.
Open ChatGPT on Android and connect to the same Windows host through Codex Remote.
Inspect the Remote project/thread list.

Actual result:

The new desktop project does not appear on Android.
The desktop-started thread does not appear on Android.
Repeating this does not make the new project visible.

Expected result:

New projects available to the connected Windows Codex host should appear in the Android Remote project selector.
Threads started inside those projects on Windows should be discoverable from Android Remote.

Asymmetric thread sync observed historically

Before the new trust-gate behavior described below:

Android -> Windows: starting a normal Codex thread from Android Remote would create/show that thread on the Windows host.
Windows -> Android: starting a thread/project on Windows after the original project would not make it appear on Android.

This asymmetry is important because it indicates that Remote connectivity itself was working while desktop-to-mobile project/thread discovery was failing.

New behavior on 2026-08-29: Android-started thread hits project trust

When attempting to start a normal new Codex thread from Android Remote, the mobile client now returns a project-trust error instead of starting normally.

The error says, in substance, that the project has not been trusted yet and must first be trusted from the Codex app on the computer, or the thread must use read-only access.

The generated Windows path shown by the error was:

C:\Users\<user>\Documents\Codex\2026-08-29\yo-3

The username is redacted here.

This is new compared with the user's previous Android-started-thread flow.

Possible workaround being tested:

Set the mobile thread to Read only before starting it.
Start the thread.
Change/elevate the access setting afterward.

This workaround is not yet confirmed as reliable or persistent.

Expected behavior

For a paired Windows host and Android Remote client:

Saved/available projects on the Windows host should be discoverable from Android Remote, not only an older/original project.
A thread started on Windows inside an eligible project should become visible on Android Remote.
A thread started from Android Remote should continue to create/show on the Windows host as before.
If a new Remote-created working directory requires trust, the product should either:
- allow the trust decision to be completed remotely when safe/appropriate, or
- clearly distinguish this from the normal thread/project flow and avoid silently creating a new untrusted project directory that blocks the thread.
Cross-device thread/project visibility should be symmetric and predictable.

Actual behavior

Original/older project: visible on both Windows and Android.
Later desktop-created project: visible on Windows, missing on Android.
Thread started inside that later desktop project: visible on Windows, missing on Android.
Historically, Android-started threads appeared on Windows.
Now Android-started thread creation can instead hit a project-trust gate for an auto-generated local Codex directory.

Why this does not look like a basic pairing failure

The original project remains available on both devices, and Android-started threads historically reached the Windows host. The failure appears to be tied to how newer projects/threads are registered, listed, trusted, or synchronized for Remote.

Possibly related issues

Regression: iOS Remote only lists projects with recent chats #36040 — iOS Remote only lists projects with recent chats. This report is different because the missing project was newly created and had a newly started thread, so it should already qualify as recent.
Windows host pairs with Android Remote, but conversations fail to load; /wham/tasks/list returns 503 #39815 / Windows Remote: QR pairing succeeds but Android clients cannot establish session (nextConnectionCount=0) on 26.818.31338 #39856 — Windows + Android Remote listing/connection problems. In this case, the host is reachable and at least the original project is visible, so the failure appears narrower.
Android Codex mobile loses Android-started active threads after force quit; permissions UI greyed out as Default only #22800 — Android-started thread visibility/persistence asymmetry. This report instead includes desktop-created projects/threads missing from Android plus the new project-trust gate.

Additional information

A screenshot of the new project-trust error is available and shows the generated Documents\Codex\2026-08-29\yo-3 path and the suggestion to trust the project on the desktop or use read-only access.

The user can provide the exact Windows Codex desktop version, screenshot, and further reproduction details if maintainers need them.

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

[Windows/Android Remote] Stale project list persists across two phones; new chats cannot be created #41197
Android Remote cannot start new task for trusted WSL2 UNC project #40519

Powered by Codex Action

Additional reproduction on 2026-08-29:

I just created another brand-new project directly in Codex on the Windows computer, then checked Codex Remote on the Android phone. The new project does not appear on the phone.

This further confirms the issue is reproducible with newly created desktop projects, not just one older video-generation project.

Current pattern remains:

Original early project: visible on both Windows and Android.
New project created on Windows: visible on Windows, missing on Android.
Historically, a thread started from Android would appear on Windows.
New Android-started thread creation is now additionally hitting the separate project-trust gate described in the main report.

So the failure appears to affect discovery/synchronization of newly created Windows projects to Android Remote.

Important update after Windows Codex Desktop update — project sync partially recovered

The project-discovery behavior changed after the latest Windows Codex Desktop update.

A project that had been created on Windows the previous night and had previously failed to appear on Android Remote was opened/used again on Windows after the update. A new thread/message was started in it specifically to test project sync (just checking sync with projects).

Result: that project now appears on Android Remote.

However, an older Windows-created project that was created during the earlier broken period still does not appear on Android.

Current A/B state is therefore:

Original early project: visible on Windows + Android.
More recent project that previously failed to sync: now visible on Android after the desktop update and renewed activity in the project.
Older project created in between: still missing on Android.

This means the current problem should no longer be described as a blanket failure where all newly created Windows projects are absent from Android. New/project sync is functioning again for at least one previously affected project, while at least one older affected project remains permanently/stale-missing.

That makes a project metadata/index/migration boundary more plausible. Possibilities worth comparing include:

project registration/index records created under different Codex Desktop builds;
stale Remote project-discovery metadata for the still-missing project;
update-time migration/reindexing that repaired some projects but did not backfill all older entries;
whether new activity/thread creation after the update caused the previously missing project to be re-registered for Remote discovery.

The still-missing older project is now a useful broken control case against both the original known-good project and the newly recovered project.

Exact post-update Windows Codex build is not captured yet.

Separate severe permission regression observed after trust-gate Read Only fallback

There is also new permission-state behavior that may be related to the trust issue, but should not be assumed to share the same root cause.

Reproduction:

Existing Codex threads were normally writable.
Start one new thread from Android Remote.
Receive the project-trust error for the generated Windows working directory.
Use the UI-suggested Read Only fallback for that one new thread.
The new thread starts successfully.
Afterward, other unrelated existing Codex threads also show Read Only.
Attempts to restore normal writable access do not reliably take effect; the Read Only state appears stuck across multiple/apparently all threads.

The user did not intentionally change those other threads to Read Only.

This raises the possibility that a setting intended to be thread-local is being persisted or applied at a broader scope (host/global/app-server/sandbox/project-trust state), or that the Android/Desktop UI and effective backend permission state have desynchronized.

Expected behavior is that selecting Read Only for one thread affects only that thread, and switching a thread back to writable access restores write capability. A project-trust fallback should never alter unrelated production threads.

This is production-blocking because affected threads can no longer modify project files.

Useful diagnostics if maintainers want to isolate it: compare effective sandbox/access policy before and after the Read Only fallback; inspect whether the permission selector changes only visually or whether backend/app-server state also remains read-only; check persistence scope for Remote-created thread access mode and project trust fallback.

Additional reproducible impact from a long-running paid Codex workflow using the same OpenAI account across Windows Codex Desktop, a Mac Codex host, and phone access:

Previously, the same task could be opened, watched, and steered from the PC, Mac, or phone. Current behavior effectively locks an active task to the device/host that is running it.

Observed on 2026-08-30:

A task was active on the Mac host.
From Windows, an attempt was made to continue/steer that exact existing task.
The destination task did not receive a normal visible user message or response. Cross-task handoff attempts produced invisible/empty turns, and attempted workarounds created extra blank-looking tasks instead of continuing the original thread.
The Windows side could not actually start a visible turn in the original task while it remained active on the Mac.
As soon as the user manually stopped/quit the task on the Mac, Windows immediately gained control and could start the turn.
This also makes phone continuity unreliable because the user cannot trust that the same visible thread is available and steerable across devices.

Expected behavior:

A task should remain one canonical, visible thread across trusted PC, Mac, and phone clients.
Every device should show the same messages and live progress.
A user should be able to steer or append to the active task from another trusted device without first stopping it on the original device.
If simultaneous steering needs serialization, the product should queue the new user message visibly and hand control over cleanly, not create invisible turns or blank duplicate tasks.
Device/host execution ownership should not make conversation visibility or user steering device-exclusive.

This is highly counterproductive for workflows intentionally split across a Windows workstation, Mac build host, and phone. The older cross-device behavior was substantially better. Please restore account-level thread visibility and predictable cross-device steering while keeping filesystem/terminal execution ownership safely host-specific.

One more deterministic reproduction of the ownership-release bug:

Task A is open/active from the MacBook host.
On the Windows Codex app, the user clicks away from Task A and opens an entirely different task.
The user then returns to the MacBook and clicks Retry on Task A.
Codex still reports that Task A is open in another app.

So simply navigating away from the task on the second device does not release its ownership/lease. The other device remains blocked even though that task is no longer the foreground task on Windows.

This suggests stale task-ownership or lease state rather than only missing cross-device synchronization. Expected behavior is that switching away should release interactive ownership promptly, or Retry should safely reclaim it. At minimum, the product should identify which device currently owns the task and provide a deliberate “Take control here” action instead of leaving both devices unable to proceed predictably.

Additional Mac host-registration evidence from the same account/workflow:

Phone remote control is functional enough to control and message Codex conversations running on both the MacBook and Windows PC.
On the MacBook, Connections shows “Control this MacBook.”
“Allow connections” is off and cannot be kept enabled.
When toggled on, the iPhone appears under devices allowed to control the Mac for a few seconds.
The device then disappears.
A red error appears at the top: “Couldn't update remote control availability.”
“Allow connections” automatically toggles back off.

This is an important split: mobile-to-existing-task routing can still work, but the Mac host cannot successfully persist or advertise its remote-control availability in Settings. That may explain stale/inconsistent host ownership, device visibility, and steering behavior.

Please log/diagnose the failure at the host availability registration/update boundary, including why a previously recognized iPhone is briefly displayed and then removed. The UI should preserve the prior known-good state or show an actionable error with retry/diagnostic details instead of silently reverting the toggle.

I’m seeing a similar issue between ChatGPT Desktop on Windows and ChatGPT iOS Remote.
The existing visible thread continues to sync, so the Remote connection itself works. However, the project and thread catalog is incomplete.

Missing threads: 15 of 16 newly created Windows threads did not appear on iOS. Sending a follow-up message to one missing thread caused it to appear.
Wrong project name: Windows shows the saved project name, "X", while iOS shows the folder basename, "Y".
Empty sidebar sections: The new custom section names created on Windows appear on iOS, but the projects assigned to those sections do not.

Restarting ChatGPT Desktop and removing and reconnecting the phone did not fix the problem.
Windows ChatGPT Desktop version: 26.825.6671.0
ChatGPT iOS version: 1.2026.230 (32543289983)

Related issues:

Additional evidence: Android Remote search and thread discovery omit intact host threads

This adds a narrower, reproducible observation to the Windows/Android Remote
discovery problem in this issue.

Environment

Host: Windows 11 Pro 25H2
Codex desktop package currently installed: OpenAI.Codex 26.901.4073.0
Affected behavior was diagnosed on desktop package 26.901.1978.0 with App
Server runtime 0.153.0-alpha.5
Remote client: ChatGPT for Android on a Samsung Galaxy Note 10+ (the exact
Android app version was not captured)
The same ChatGPT account is used on both devices. Remote is paired and online;
ordinary messages work in both directions.

Expected behavior

Android Remote should list and search all existing, unarchived threads from the
connected host within their projects.

Actual behavior

The host had three healthy projects and nine real, unarchived threads.
Android showed exactly two threads per project, and the global list stopped
after five recent threads with no further threads available.
Searching Android Remote for the exact title of a known existing, inactive
host thread returned no result.
Three affected threads were confirmed readable, idle, project-bound, and
intact on the host.
Pinning an affected thread on the host made it appear on Android immediately;
removing the pin made it disappear from Android again.

This points to a mobile Remote list/search discovery or indexing boundary, not
to host-side data loss.

Reproduction

On a paired Windows Codex host, keep several existing unarchived threads in
more than one project, including older inactive threads.
Open ChatGPT on Android and connect through Codex Remote.
Compare the project thread lists with the host list, then search Android
Remote for the exact title of one of the known host threads missing from the
normal list.
Pin that same thread on the host and refresh/reopen the Android list.
Observe that the thread becomes visible immediately; remove the pin and
observe that it is no longer visible in the normal Android list.

Troubleshooting already performed

Cleared Android app storage and set the app up again: no change.
Re-paired Remote: no change.
Created/refreshed a project anchor and a new mobile root thread: the project
became visible, but older threads remained missing.
Re-published the affected thread titles without changing them: no change.
Opened the affected host threads read-only without starting a turn: no change.
During the failed mobile exact-title search, the desktop side showed no
corresponding host search request or App Server error.

Host project registration, SQLite integrity, App Server reachability, WebSocket
connectivity, and normal host list requests were healthy. The pin workaround is
confirmed end-to-end on Android, but it is only a reversible visibility
workaround, not a repair.

Request

Could the team investigate whether Android Remote applies an unintended
per-project/recent-list cap or fails to backfill/search existing host threads?
If useful, I can provide sanitized screenshots and narrowly scoped diagnostics
privately. I will not post full transcripts, account identifiers, local paths,
or unfiltered logs publicly.

Additional Windows/Android confirmation: Desktop project/thread are healthy, but Android Remote still does not show the Project

I can confirm that the missing-Project behavior persists independently of a separate local thread-history projection failure.

On the Windows host, the affected Project and its chat/thread open normally in Codex Desktop and the local conversation history is current. A separate duplicate-ordinal history-projection problem in one thread was repaired locally, restoring its missing recent history, but this had no effect on Android Remote Project visibility.

Current state:

Windows Codex Desktop: Project is present and opens normally.
Windows Codex Desktop: affected chat/thread opens normally.
Android ChatGPT Codex Remote: the Project is still missing/not surfaced correctly.
Repairing the local thread-history projection did not make the Project appear on Android.

This strengthens the conclusion that the Project visibility failure is in the Windows-host -> Android Remote project inventory/projection path, rather than being caused by a broken local thread-history index.

There is also a separate Remote hydration symptom in a realtime-Voice-created thread: an image-generation section stays indefinitely in a loading state on Android while the same Project/thread can be opened normally on the Windows host. I am filing that separately because it appears to be item/history hydration rather than Project discovery.

Additional repro detail: stale Project membership survives a move/delete on Windows.

Observed sequence:

A realtime-Voice-created thread was archived on Windows.
Immediately after that archive action, a Project that had previously been missing from Android Remote suddenly appeared on Android.
On Windows, the remaining AIRI thread was then moved out of that Project back to the general Chats / No-project area.
The now-empty Project was deleted on Windows.
Windows reflects both changes correctly: the AIRI thread is no longer in the Project, and the Project itself is gone.
Android Remote still shows the deleted Project.
Android Remote also still shows the AIRI thread as if it were still a member of that deleted Project.
Opening that stale thread entry on Android remains stuck loading indefinitely.

This looks stronger than a simple stale project-name cache. The Remote side appears to retain a stale Project -> thread membership edge even after the host has removed the thread from the Project and deleted the Project itself.

The archive action causing the previously missing Project to suddenly appear is also notable. It suggests Remote Project discovery may be triggered/rebuilt from thread activity, while removal/move/delete invalidation is not being propagated symmetrically.

Current host state remains healthy on Windows; the mismatch is visible only on Android Remote.

I can reproduce the missing-project/trust-gate variant on Android Remote → macOS, and have host-side state evidence that the trust error can be downstream of a missing app-server project registration rather than a missing trust decision.

Environment:

Codex Desktop 26.901.41123 (build 7942)
Bundled CLI/app-server 0.153.3; persistent Remote helper uses the official npm CLI 0.153.4
Host: Darwin 25.5.0 arm64 arm
Android Remote client

Observed state for an existing project selected on Android:

The exact original path still existed and had an explicit trust_level = "trusted" entry in ~/.codex/config.toml.
Android still displayed the project, but starting the task failed with Can't verify project trust for <original-path>.
The live app-server project/list returned 14 projects and omitted that path.
The SQLite project catalog also omitted it.
Twenty existing threads still had that exact cwd, but all 20 had a null project association.
Desktop logs recorded Local app-server project migration completed projectCount=14, so the migration completed without importing this previously saved/trusted project.

Repair control:

Importing the existing directory through the supported experimental project/import API created one project row and atomically attached all 20 existing threads.
The persistent Remote daemon then returned 15 projects and included the repaired path, without changing the trust entry.

This looks like a registration/migration failure with stale mobile project state: Remote can retain/display a project that the host's authoritative project catalog no longer contains, then surface a misleading trust error for the already-trusted original directory. A useful invariant would be to preserve all saved project roots during migration and either invalidate stale Remote project entries or report “project no longer registered” separately from trust validation.

I have kept raw logs and the pre-repair SQLite/config backup locally; they contain unrelated private paths and identifiers, but I can provide targeted redacted excerpts if useful.

Follow-up to my project-registration report: after importing the missing project and subsequently restarting the persistent Remote app-server, the Android user confirmed that new threads can be started and the previously unresponsive controls work again. Some intermittent lag remains.

The host checks after restart returned configuration in about 20 ms and permission profiles in about 10 ms; those requests had previously timed out. This is a recovery observation, not an isolated reproduction: both project registration and a service restart occurred before the phone-side confirmation, so I cannot attribute the recovery to either change alone.

One correction to my earlier interpretation: the catalog count and migration log establish that the project was absent after migration, but do not prove that migration itself removed it. The prior saved-project state may already have been incomplete.

Recovery update / possible clue about Remote state reconciliation:

After the stale Project/thread membership behavior described above, the Android side now appears to be working again after this sequence:

Removed the ChatGPT Android beta build / beta installation.
Reinstalled ChatGPT on Android.
Re-established the Codex Remote connection/pairing to the same Windows host.

After the fresh install + re-pair, the previously stale Project/thread state appears to have reconciled correctly.

This does not prove the Android beta build alone was the root cause, because reinstalling and re-pairing also reset local client state and the Remote enrollment/session. Given the earlier symptoms — a missing Project suddenly appearing after archiving a thread, followed by a deleted Project and moved thread remaining visible as stale membership on Android — this still looks consistent with a stale Remote Project/thread projection or enrollment/session state that was not fully reconciled until a fresh pairing.

So at least in this case, a full Android beta removal + reinstall + fresh Remote pairing acted as an effective recovery path. It would be useful to know whether the re-pair forces a full host Project/thread inventory rebuild while normal reconnects use incremental state.

I am seeing a closely related Android Remote asymmetry with a Linux desktop host and the current ChatGPT Android app.

Codex/Work threads are visible in the ChatGPT app's conversation/history surfaces, but Remote resumability appears to depend on how the thread originated. In my current use, threads that were started through the desktop app can be opened remotely from Android, while other Codex-originated threads that are nevertheless visible in ChatGPT cannot be opened/resumed the same way.

So this is not simply a case of the conversation being absent from ChatGPT history: the mobile client can know about the thread, but Remote does not consistently make it resumable.

Expected behaviour: if a Codex thread is associated with the connected Linux host and is visible to the same account, its Remote availability should be predictable regardless of whether it was originally initiated through the desktop UI or another Codex surface. If some thread origins are intentionally not remotely resumable, the UI should identify that explicitly rather than showing a thread that cannot be opened remotely.

Observed 7 Sep 2026 on Linux + ChatGPT Android / Codex Remote. I can provide a more controlled origin-by-origin reproduction if useful.

New Windows/Android Remote reproduction showing a stronger cross-device turn-persistence failure:

On Android Remote, open an existing Windows-hosted Codex thread.
Send a new user message from Android.
The message is visibly accepted on Android and the assistant begins generating a response.
Back out of the thread while the response is still in progress.
The corresponding turn/message never appears on the Windows Codex desktop thread.
Reopen the Android thread later: the Android-sent message and the partial assistant response are gone as well, with the thread reverted to the earlier state.

This is different from a pure Android rendering/hydration failure because the Windows host never receives/displays the turn at all. The mobile client can temporarily enter a live turn that does not become durable/shared thread state, then loses it after navigation/reload.

Impact: user-authored instructions can appear accepted and begin executing on mobile, but then disappear entirely and never reconcile to the Windows host. This makes Android Remote unsafe for production work because the UI can report a successful turn start without durable cross-device persistence.

Related observed environment symptoms in the same Windows/Android setup include stale/duplicate Remote host state, projects that appear/disappear from the mobile project list, and previous thread-history hydration issues.

Additional deterministic Windows/Android reproduction

I can confirm this on a Windows host with the ChatGPT Android Remote client.

The local project and its chats are present and readable on Windows, but the project initially did not appear in Android Remote. Restarting both apps and fully removing and re-pairing the Remote connection did not fix it.

A reproducible visibility trigger was found:

Leave all chats in the affected local project unpinned on the Windows host.
Refresh or reopen Android Remote: the project is absent.
Pin any chat belonging to that project on Windows.
Refresh or reopen Android Remote: the project appears.
Unpin every chat in the project.
Refresh or reopen Android Remote: the project disappears again.
Re-pin one project chat: the project reappears.

The Android client also displays the folder basename instead of the saved desktop project label.

This suggests Android Remote project discovery is being derived from or gated by the pinned-thread inventory, rather than consistently loading the host's project catalog. The host project remains intact throughout; no local data loss was observed.

All paths, account identifiers, project names, and screenshots are intentionally omitted.

Additional reproduction from another Windows Codex Desktop + ChatGPT Android Remote user (2026-10-09):

Regular threads created in the Windows desktop app do not show up in Android Remote's normal project/thread list.
Pinning one of those desktop-created threads makes that exact thread appear on Android under Pinned threads.
Opening the pinned thread on Android, sending further instructions, and viewing the responses works; changes are visible back in the same thread on Windows. Therefore the host connection and bidirectional thread interaction work.
Despite that, the regular thread/project discovery list still does not refresh or show the missing desktop-created threads.
The same workspace folder also shows different project names between Windows Desktop and Android Remote; renaming/display-name changes made on Desktop do not propagate to Android (likely related to Windows/Android Remote shows folder basename instead of the saved Desktop project name #36754).

Expected: All eligible desktop project threads should be discoverable without pinning, and both devices should show the same saved project display name.

Impact: Remote operation of multiple concurrent development threads from mobile requires manually pinning every thread, and differing project labels make it difficult to identify the correct workspace.

This is a user-observed reproduction, not a claim that pinning fixes the underlying issue. Desktop build / Android build not captured.

Navigation Menu

Repository navigation

[Windows/Android Remote] New desktop projects/threads do not appear on mobile; original project syncs, mobile-started thread now hits trust gate #41470

Summary

Environment

Known-good baseline

Broken behavior: later desktop projects

Asymmetric thread sync observed historically

New behavior on 2026-08-29: Android-started thread hits project trust

Expected behavior

Actual behavior

Why this does not look like a basic pairing failure

Possibly related issues

Additional information

Important update after Windows Codex Desktop update — project sync partially recovered

Separate severe permission regression observed after trust-gate Read Only fallback

Additional evidence: Android Remote search and thread discovery omit intact host threads

Environment

Expected behavior

Actual behavior

Reproduction

Troubleshooting already performed

Request

Additional Windows/Android confirmation: Desktop project/thread are healthy, but Android Remote still does not show the Project

Additional deterministic Windows/Android reproduction

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Windows/Android Remote] New desktop projects/threads do not appear on mobile; original project syncs, mobile-started thread now hits trust gate #41470

Description

Summary

Environment

Known-good baseline

Broken behavior: later desktop projects

Asymmetric thread sync observed historically

New behavior on 2026-08-29: Android-started thread hits project trust

Expected behavior

Actual behavior

Why this does not look like a basic pairing failure

Possibly related issues

Additional information

Activity

github-actions commented on Aug 29, 2026

ajackxthegather commented on Aug 29, 2026

ajackxthegather commented on Aug 29, 2026

Important update after Windows Codex Desktop update — project sync partially recovered

ajackxthegather commented on Aug 29, 2026

Separate severe permission regression observed after trust-gate Read Only fallback

GREEN08173 commented on Aug 30, 2026

GREEN08173 commented on Aug 30, 2026

GREEN08173 commented on Aug 30, 2026

thednaz commented on Aug 31, 2026

Cintao66 commented on Sep 4, 2026

Additional evidence: Android Remote search and thread discovery omit intact host threads

Environment

Expected behavior

Actual behavior

Reproduction

Troubleshooting already performed

Request

anjel2026 commented on Sep 5, 2026

Additional Windows/Android confirmation: Desktop project/thread are healthy, but Android Remote still does not show the Project

anjel2026 commented on Sep 5, 2026

Jackten commented on Sep 5, 2026

Jackten commented on Sep 5, 2026

anjel2026 commented on Sep 6, 2026

ccaprani commented on Sep 7, 2026

ajackxthegather commented on Sep 9, 2026

Rumblewand commented on Sep 13, 2026

Additional deterministic Windows/Android reproduction

ichiaku commented on Oct 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions