Copilot App 1.1.8 still gated by org "Copilot CLI" policy despite "GitHub Copilot app" policy being Enabled

[Jucojo]

Describe the bug

The org-level policy UI for GitHub Copilot app states:

If enabled, members of this organization can use the GitHub Copilot app. Enforcement begins July 27th, 2026 in version 1.1 of the GitHub Copilot app. The Copilot CLI policy continues to govern the GitHub Copilot App until version 1.1

On GitHub Copilot app 1.1.8 (past that cutover), with the org configured as:

• GitHub Copilot app = Enabled (enterprise-enforced)
• Copilot CLI = Disabled (org-level)

members still cannot use the Copilot app at all. Model listing fails immediately and every prompt is rejected.

The app's own entitlement gate appears to pass correctly — it is the CLI engine the app spawns that is denied.

Symptoms seen by affected members:

Model list on startup:

Failed to list models: RPC error -32603: Request models.list failed with message: 403 "unauthorized: not authorized to use this Copilot feature\n"

Any prompt:

You are not authorized to use this Copilot feature, it requires an enterprise or organization policy to be enabled.
Request ID: 813D:3FB9FB:48AA19:54AD00:6A7E2287

App-side log:

ERROR github_app::handlers::misc: failed to list models
error=RPC error -32603: Request models.list failed with message:
403 "unauthorized: not authorized to use this Copilot feature\n"

Evidence that the app gate passes but the engine gate does not:

1. The app binary's CopilotUserResponse struct parses copilot_app_enabled and does not contain cli_enabled — so the app itself honors the documented ≥1.1 behavior.
2. The app spawns the CLI as its engine:

   ~/Library/Caches/github-copilot-sdk/cli/1.0.79-9/copilot --server --stdio --no-auto-update
   

3. The failure surfaces as an RPC error from that subprocess (RPC error -32603: Request models.list), i.e. the engine's own API call is what gets the 403.

So copilot_app_enabled: true has no practical effect while cli_enabled: false, which is the opposite of what the policy text promises at 1.1+.

GET https://api.github.com/copilot_internal/user for an affected member returns:

{
  "cli_enabled": false,
  "copilot_app_enabled": true,
  "copilot_plan": "enterprise",
  "organization_login_list": ["<org>"]
}

Affected version

GitHub Copilot app 1.1.8 (macOS, arm64); bundled engine ~/Library/Caches/github-copilot-sdk/cli/1.0.79-9/copilot

Steps to reproduce the behavior

1. In an organization on an enterprise plan, set GitHub Copilot app = Enabled and Copilot CLI = Disabled.
2. As a member whose Copilot seat comes only from that organization, sign in to the GitHub Copilot app 1.1.8.
3. Observe the model picker fail with Failed to list models: RPC error -32603: ... 403 "unauthorized: not authorized to use this Copilot feature".
4. Send any prompt (e.g. say hi) and observe You are not authorized to use this Copilot feature, it requires an enterprise or organization policy to be enabled.
5. Confirm the entitlement split via GET https://api.github.com/copilot_internal/user — copilot_app_enabled: true, cli_enabled: false.

Expected behavior

At app version ≥ 1.1, the GitHub Copilot app policy alone should govern the app, per the policy UI text. With copilot_app_enabled: true, the app and the engine it spawns on the user's behalf should both be authorized, and cli_enabled: false should not block it.

Concretely: requests the app makes through its bundled copilot --server --stdio engine should be evaluated against copilot_app_enabled, not cli_enabled.

Today the only workaround is to enable the Copilot CLI org policy — which defeats the purpose of the two policies being separate, and forces admins to permit standalone terminal CLI use in order to allow the desktop app.

Additional context

• Operating system: macOS (Darwin), ARM (arm64)
• Org plan: enterprise
• Request ID: 813D:3FB9FB:48AA19:54AD00:6A7E2287
• Org name redacted as <org> above.

Possibly related — entitlement resolving across enterprise boundaries

While diagnosing this, we noticed that an org owner with a Copilot seat in a second, unrelated organization was unaffected. Their copilot_internal/user returned cli_enabled: true with:

"organization_login_list": ["<org-a>", "<org-b>"]

<org-b> enforces its own SAML SSO (so it belongs to a different enterprise), and the token in use was not SSO-authorized for it. The policy docs scope least-restrictive resolution to "multiple organizations in the same enterprise":

A user can receive access to Copilot from multiple organizations in the same enterprise. If these organizations have configured the same policy differently, the least restrictive policy usually applies.

If least-restrictive resolution is in fact spanning enterprises, an admin cannot enforce a Copilot policy on any user who holds a seat elsewhere. Filing here for visibility; happy to move that to Support if it is better handled there.