Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Feature: per-toolset (or per-tool) read-only mode instead of global GITHUB_READ_ONLY

Ouverte
#3,229 2 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
42/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
github, go
Domaine
backend-api-design, security

Piste de recherche

Commencez par retracer la manière dont le serveur gère GITHUB_READ_ONLY et la configuration GITHUB_TOOLSETS existante, puis identifiez où les outils d’écriture sont distribués. Comparez les scopes proposés par toolset et par outil avec le comportement actuel de la configuration. Le travail est considéré comme terminé lorsque certaines opérations d’écriture sélectionnées sont rejetées, tandis que les lectures et les écritures explicitement autorisées continuent de fonctionner, avec une couverture pour la configuration choisie.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

enhancement policies & governance
Feature request

GITHUB_READ_ONLY is currently all-or-nothing: when set, the whole server rejects every write operation. There is no way to keep some domains writable while others stay read-only.

Use case

Running the server as a local coding-agent tool with a single GitHub token, I want a common "safe by default" posture:

  • Reads everywhere (repos, issues, pull requests) allowed without human confirmation
  • Writes (merge PR, close/label issues, push comments) gated behind explicit user approval

Today the only way to approximate this is to launch two full server instances — one with GITHUB_READ_ONLY=1 and one without — and rely on agent-side conventions to route writes to the second instance. That is fragile because nothing on the server side prevents an agent from calling write tools on the writable instance, and it doubles the tool surface / process count.

Proposed solution

Any of the following would fix it:

  1. Per-toolset read-only, e.g. GITHUB_READ_ONLY_TOOLSETS=issues,pull_requests (writes rejected only for the listed toolsets), or
  2. Per-tool read-only overrides, e.g. a GITHUB_READ_ONLY_TOOLS=merge_pull_request,create_issue deny list, or
  3. A "write-confirm" layer that rejects write tools unless an opt-in env var for that specific call is present.

Option 1 seems the most consistent with the existing GITHUB_TOOLSETS design.

Alternatives considered
  • Token scoping (fine-grained PAT without write scopes): does not help, because the same token is also expected to perform approved writes.
  • Dual-instance setup: works only as a convention, not enforcement (described above).
Langage dominant
Go
Étoiles
33.1k
Forks
5k
Merge moyen
2 j 1 h
PR mergées (30 j)
25

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de github/github-mcp-server

Toutes les issues de github/github-mcp-server

Issues similaires

Plus d'issues Go

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.