Feature: per-toolset (or per-tool) read-only mode instead of global GITHUB_READ_ONLY
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 42/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- github, go
- Lĩnh vực
- backend-api-design, security
Hướng nghiên cứu
Bắt đầu bằng cách theo dõi cách máy chủ xử lý GITHUB_READ_ONLY và cấu hình GITHUB_TOOLSETS hiện có, sau đó xác định nơi các công cụ ghi được phân phối. So sánh các scope được đề xuất theo toolset và theo tool với hành vi cấu hình hiện tại. Được coi là hoàn thành khi các thao tác ghi được chọn bị từ chối, trong khi các thao tác đọc và các thao tác ghi được cho phép rõ ràng vẫn tiếp tục hoạt động, với độ bao phủ cho cấu hình đã chọn.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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:
- Per-toolset read-only, e.g.
GITHUB_READ_ONLY_TOOLSETS=issues,pull_requests(writes rejected only for the listed toolsets), or - Per-tool read-only overrides, e.g. a
GITHUB_READ_ONLY_TOOLS=merge_pull_request,create_issuedeny list, or - 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).
- Ngôn ngữ chính
- Go
- Star
- 33.1k
- Fork
- 5k
- Merge trung bình
- 2 ngày 15 giờ
- Pull request đã merge (30 ngày)
- 27
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của github/github-mcp-server
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
github/github-mcp-server#3235 ·
-
enhancement
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
github/github-mcp-server#3042 · 2 bình luận ·
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
github/github-mcp-server#3032 · 1 reaction ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
github/github-mcp-server#2803 · 1 bình luận ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
github/github-mcp-server#2740 ·
Tất cả issue của github/github-mcp-server
Issue tương tự
-
kind/bug needs-triage
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 72/100
matrixorigin/matrixone#29223 ·
-
needs-acceptance wg/data-plane-networking
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
vllm-project/semantic-router#4024 · 1 bình luận ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
alexgorbatchev/dotfiles#107 ·
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 84/100