Per-ChatGPT-Project GitHub repository permissions (read-only / read-write / no access)

What feature would you like to see?

Please add per-ChatGPT-Project GitHub repository access control, so that repositories exposed through the GitHub connector can be assigned independently to each ChatGPT Project with explicit permission levels.

Suggested repository-level permissions:

• NO_ACCESS
• READ_ONLY
• READ_WRITE

The same connected GitHub account should be able to expose different repositories, with different permissions, to different ChatGPT Projects.

Problem

Today, a GitHub connector is effectively shared at the account/app level. A ChatGPT Project can use the connector, but there is no sufficiently granular way to say:

Project A may write repository X, while Project B may only read repository X, and Project C must not access repository X at all.

This makes it difficult to implement least-privilege security for workflows where multiple ChatGPT Projects interact with the same GitHub account.

A concrete example:

• ChatGPT Project: Protocolli
  • gdicroce/protocolli → READ_WRITE
• Other ChatGPT Projects
  • gdicroce/protocolli → READ_ONLY
• Unrelated repositories
  • optionally NO_ACCESS

The repository contains shared governance/protocol definitions used by many projects. Other projects need to inspect those definitions, versions, and compatibility metadata, but they should not be able to change the canonical repository.

Without project-scoped repository permissions, this separation can only be expressed as a prompt-level convention or enforced manually outside ChatGPT. That is not a strong security boundary.

Proposed behavior

In each ChatGPT Project, provide a GitHub access configuration such as:

GitHub repositories

owner/repository-a    READ_WRITE
owner/repository-b    READ_ONLY
owner/repository-c    NO_ACCESS

A useful UI could live under the Project's connected apps / tools settings.

The permission should be enforced by the connector/tool layer, not only by model instructions.

For example, when a Project has READ_ONLY access to a repository, mutating GitHub operations should not be available or should be rejected before execution, including actions such as:

• creating/updating/deleting files;
• pushing commits;
• creating or deleting branches where mutation is involved;
• merging pull requests;
• changing repository settings.

Read operations should remain available.

Security properties

The feature should ideally provide:

1. Default deny / explicit repository assignment where desired.
2. Repository-level allowlists per ChatGPT Project.
3. Separate READ_ONLY and READ_WRITE capabilities.
4. No implicit permission expansion because another Project has broader access.
5. Project-level revocation without disconnecting GitHub globally.
6. Clear visibility of the effective permission before an operation is executed.
7. Auditability of which Project initiated a GitHub mutation.

Why this matters

This would allow ChatGPT Projects to become real security/governance boundaries rather than only organizational/context boundaries.

It would be especially useful for:

• shared configuration repositories;
• policy/protocol repositories;
• infrastructure repositories;
• production repositories;
• documentation repositories used by several projects;
• organizations applying least-privilege access principles.

Optional future extensions

The same model could later support finer scopes such as:

• branch-specific write access;
• pull-request-only write access;
• issue-only permissions;
• repository administration permissions;
• different permissions for different connected apps/tools inside the same Project.

The core request, however, is simply:

Allow users to assign GitHub repositories to individual ChatGPT Projects and specify READ_ONLY, READ_WRITE, or NO_ACCESS per repository, with enforcement at the connector/tool layer.

Product area

ChatGPT Projects / GitHub connector / Codex integrations

The issue names no source files, tests, or implementation entry points. First map the ChatGPT Project and GitHub connector integration boundaries, then determine where repository permissions are stored and enforced; done means project-specific NO_ACCESS, READ_ONLY, and READ_WRITE behavior is defined and protected across the listed mutation operations.