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

まず、サーバーが GITHUB_READ_ONLY と既存の GITHUB_TOOLSETS 設定をどのように処理するかを追跡し、次に書き込みツールがどこでディスパッチされるかを特定します。提案されている toolset 単位および tool 単位のスコープを、現在の設定動作と比較します。選択した書き込み操作が拒否され、読み取りと明示的に許可された書き込みが引き続き機能し、選択した設定に対するカバレッジがあることを完了条件とします。

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).