Skip to content

/share gist fails with "Rate Limit Exceeded" for EMU users #1814

@toby

Description

@toby

Bug Report

Reported by: EMU (Enterprise Managed User) account users

Description

EMU users are reporting that /share gist fails with a rate limit error when attempting to create a secret gist:

✗ Failed to share session: HttpError: Rate Limit Exceeded - https://docs.github.com/rest

Analysis

The /share gist flow in src/cli/commands/slashCommands.ts calls shareSessionToGist() which uses the user's OAuth token (obtained via device flow with scope read:user,read:org,repo,gist) to create a gist via POST /gists through Octokit in src/cli/github/client.ts.

The current getGistToken() validation checks:

  1. User is logged in
  2. Host is not *.ghe.com (GHE Cloud with data residency)
  3. Token is non-null

There is no EMU-specific handling. EMU accounts on github.com pass all three checks, but may be subject to enterprise policies that restrict gist creation or impose different rate limits. The GitHub API may return a misleading "Rate Limit Exceeded" error instead of a clear 403/policy error.

Relevant Code

  • src/cli/commands/slashCommands.tsgetGistToken() (line ~2909) and executeShareGistCommand() (line ~2959)
  • src/cli/github/client.tscreateGist() (line ~160)
  • src/core/github/gitHubApi.ts — OAuth scope: read:user,read:org,repo,gist (line ~65)

Questions to Investigate

  1. Do EMU enterprise policies block gist creation, and does the API surface this as a rate limit error?
  2. Should we detect EMU accounts and show a more helpful error message (e.g., "Your enterprise may restrict gist creation — try /share file instead")?
  3. Is the Copilot CLI OAuth token treated differently for EMU users w.r.t. API rate limits?

Reproduction

  1. Log in to Copilot CLI with an EMU account on github.com
  2. Start a session and have some conversation
  3. Run /share gist
  4. Observe "Rate Limit Exceeded" error

Expected Behavior

Either gist creation succeeds, or the user gets a clear, actionable error message explaining why it failed (e.g., enterprise policy restriction) with a suggestion to use /share file as a fallback.

Metadata

Metadata

Assignees

No one assigned

    Labels

    msft-dogfoodMicrosoft dogfood feedback

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions