No indication when `cli_remote_control_enabled` is false — desktop setting is inert and GitHub Mobile returns a bare HTTP 422

[alexpfau]

Describe the bug

When the signed-in account's Copilot entitlement has cli_remote_control_enabled: false, neither the desktop app nor GitHub Mobile indicates it. Instead the feature appears available and fails opaquely:

• Settings → General → "New sessions remote access" can be changed and the preference persists, but has no effect.
• Sessions are created and run normally, but availability is never published for remote control.
• Sending a message to such a session from GitHub Mobile fails with a bare HTTP 422 and no explanation.

The result is a feature that looks configurable and simply isn't. Diagnosing this took a long investigation across the app database, the app log, and the shipped binary before /copilot_internal/user revealed the cause was an account entitlement rather than a misconfiguration or a local fault.

Affected version

GitHub Copilot desktop app 1.1.6 (macOS, Apple Silicon); Copilot CLI 1.0.79-5; GitHub Mobile on iOS.

Steps to reproduce the behavior

1. Sign in to the desktop app with an account whose /copilot_internal/user returns cli_remote_control_enabled: false — for example an enterprise seat where the policy is turned off. Note that cli_enabled, chat_enabled, copilot_app_enabled and cloud_session_storage_enabled may all be true.
2. Open Settings → General and set New sessions remote access to the permissive option.
3. Create a new repository-backed session and let it run.
4. On GitHub Mobile, open that session and send a message.

The mobile app returns HTTP 422. Nothing is logged on the desktop side, because the request never reaches the host.

Expected behavior

Any one of the following would make this self-diagnosing:

1. Disable or grey out New sessions remote access when cli_remote_control_enabled is false, with a note such as "Remote access is turned off for your organization."
2. Return an actionable error to GitHub Mobile instead of a bare 422 — for example "Remote control is not enabled for your account."
3. Include a machine-readable reason in the 422 response body.

Option 1 alone would be sufficient, since it prevents the user reaching the failure state at all.

Additional context

Evidence gathered while diagnosing, in case it helps locate the gap.

The desktop app never checks the entitlement. The string copilot_internal/user appears 0 times in a 5.4 MB app log covering a full day of use. The app's complete outbound API surface over that period was: repository issues, PR timelines, PR comments and reviews, copilot_internal/.../merge_status, alive_internal/websocket-url, cmc_internal/api/agents/.../automations/v2, and telemetry. Nothing entitlement-related and nothing session-registration-related.

Availability is never published, and nothing surfaces that. In ~/.copilot/data.db, across all 19 sessions created between 2026-05-28 and 2026-08-08, the columns remote_availability, remote_prompt_delivery, remote_create_state and remote_connect_target have been NULL 100% of the time, and remote_availability_revision has never held any value other than 0. That is consistent with the client correctly declining to publish for an unentitled account — the issue is purely that the decision is invisible.

The stored preference is honoured locally, then ignored. app_state.remote-session-default reads {"state":{"defaultRemoteSessionMode":"on","hasUserSetPreference":true},"version":1}, and newly created sessions carry remote_session_mode = 'on' with remote_control_enabled = 1 at both session and project level. So the setting writes through correctly and then silently does nothing, which strongly implies a local misconfiguration to anyone debugging it.

Failures leave no local trace at all. No genuine HTTP 422 is ever logged on the desktop side, and the app holds only two established outbound connections to GitHub — the REST endpoint and the Alive socket, the latter carrying only PR resource snapshots. There is no local signal a user could use to work out what happened.

What continues to work is what made this confusing. Plain non-repository chats work from mobile, and cloud sessions work from mobile. Both are consistent with chat_enabled: true and cloud_session_storage_enabled: true while only cli_remote_control_enabled is false — but from the user's side it just looks like "some sessions work from my phone and some return 422."

Related: #2751 notes that /remote cannot be invoked at all unless an admin has enabled remote access, so the CLI does gate on this. The desktop app and mobile app appear not to.

Happy to supply further detail from the app database or log if useful.