GitHub plugin: expose Codespaces access and Codespaces permission scope

What feature would you like to see?

Please extend the native GitHub plugin / ChatGPT Codex Connector so a connected GitHub account can work with GitHub Codespaces directly, instead of exposing only repository / issue / PR / Actions surfaces.

A minimal useful first slice would expose read and lifecycle operations such as:

codespace list
codespace view
codespace create
codespace start
codespace stop
codespace delete

with the corresponding GitHub Codespaces permission requested only when the user enables this capability.

A second, separately gated capability could expose bounded command execution in an existing Codespace (similar in purpose to gh codespace ssh / remote command execution), with clear user approval and capability metadata. This does not need to include Codespaces secret management in the first version.

Current gap

In the current native GitHub plugin tool surface, repository, Issues, PRs, commits, Actions, files, reviews, and related operations are available, but no Codespaces operations are exposed.

This creates an awkward split for workflows that intentionally use Codespaces as an ephemeral execution environment:

ChatGPT GitHub plugin
  -> can inspect repository state
  -> cannot inspect or control the repository's Codespace

external CLI / bridge
  -> required for Codespace lifecycle or execution

The result is extra orchestration and often a second authentication path solely to reach the ephemeral environment.

Why this is feasible at the GitHub permission layer

GitHub's current Codespaces REST API supports GitHub App user access tokens and fine-grained tokens for Codespaces operations. GitHub App permissions include a codespaces repository permission (read / write), while classic OAuth tokens use the codespace scope for the relevant endpoints.

So the request is not for an undocumented GitHub capability; it is for the native plugin to expose and request the existing Codespaces permission when explicitly enabled.

Suggested permission / safety model

Keep this opt-in and capability-scoped:

1. Default GitHub plugin behavior remains unchanged.
2. Enabling Codespaces requests only the smallest required Codespaces permission.
3. Read/list/view can use read permission.
4. Create/start/stop/delete require write permission and should remain explicit mutations.
5. Remote command execution, if added, should be a separate clearly visible capability rather than being implied by repository access.
6. Secret values should not be exposed merely because Codespaces access is enabled.

Example workflow

A useful research / development flow is:

ChatGPT
  -> inspect current GitHub issues / PRs
  -> open or resume a short-lived Codespace
  -> run a bounded verifier / test there
  -> inspect the result
  -> stop the Codespace

Today the GitHub plugin can do the first step but not the Codespace steps, which forces an additional bridge even though both resources belong to the same GitHub account and repository.

Expected outcome

The GitHub plugin can optionally act as one coherent GitHub control surface for repository state plus ephemeral Codespace execution, while preserving least privilege and explicit mutation boundaries.

Start by locating the native GitHub plugin tool surface and its existing permission or capability handling; the payload names no files or tests. Map the requested Codespaces lifecycle operations and permission boundaries, then define separate read, mutation, and optional command-execution capabilities with explicit approval and no implicit secret access.