A seat that can edit, test and stage cannot land: git commit is the one write with no tool surface

Context

Measured tonight (2026-08-06/07) by @neo-gpt at 0% remaining Codex quota, and reported verbatim:

"The substrate boundary is now exact: file edits, tests, issue updates, A2A, and git add all worked at 0%, but git commit was rejected by the quota gate with the Aug 8 reset message."

Extended the same night, and this is the datapoint that moves the premise from one measurement to a consistent envelope — also @neo-gpt, ~40 minutes later:

"Managed manage_pr_review succeeded at 0% quota, so authenticated MCP review mutation is currently available even though shell git commit is gated."

manage_pr_review is a write that mutates a public artifact. So the gate is not "no writes at 0%" and not "no side effects" — it is specifically the shell. Measured envelope at 0%: file edits ✓, test runs ✓, git add ✓, issue body writes ✓, A2A ✓, public review mutation ✓, git commit ✗.

That reframes the governance question below rather than settling it: a commit tool would not be opening a new channel, it would be extending one that demonstrably already carries write authority over public artifacts. Whether that makes it more legitimate (consistency across writes) or less (the existing breadth is itself the accident) is exactly what needs deciding.

So the capability envelope of a quota-exhausted seat is: it can do everything except land the work. He implemented #16167 to completion — a validated four-file diff, staged, branch clean off origin/dev — and it is still sitting uncommitted in his clone. A reviewer-capable, test-capable, fully-productive seat is blocked on exactly one shell call.

Operator framing that opened this:

"maybe worth a feature request ticket to add commit and push MCP tools into OUR own github workflow MCP server."

The Problem

Every other write an agent performs has a tool surface. Git writes do not.

Issues, PRs, reviews, labels, assignees, discussions, comments, memories, messages — all reachable through MCP. git commit and git push are reachable only through the shell, so they inherit whatever the harness allows the shell to do. When a harness gates shell execution, the agent loses the one capability with no alternate path, and the loss is total rather than graceful: there is no degraded mode where the work still lands.

This is not primarily about quota. Quota is tonight's trigger; the structural fact is that the git write is the only unmediated one. Consequences beyond a rate-limited seat:

• No gate can be enforced on it. Every other write passes through ToolService, where we can attach refusals, contracts and audit. Git writes are enforced only by husky hooks, which live in the clone and are bypassable by anyone typing --no-verify. Our §critical_gates rule 3 (never commit to main/dev) is discipline-only — there is no mechanical guard, which AGENTS.md states outright for rule 1 and is equally true here.
• No receipt. A commit produces no structured result an agent can assert on, so "did it land, and with which gates run" is reconstructed from shell text.
• Cross-harness asymmetry. Seats differ in what their shell permits, so the same lane is landable by one family and not another for reasons unrelated to the work.

The Architectural Reality

ai/services/github-workflow/ already executes git. Five of its fifteen services shell out today — SyncService, PullRequestService, IssueService, HealthService, GraphqlService. SyncService is the strongest precedent: the data-sync pipeline is the one documented exception to the no-direct-commit rule (AGENTS.md §critical_gates 3), so a service in this folder already commits and pushes under a named authority. This is not a new capability class in the codebase; it is an existing one with no tool surface.

github-workflow MCP runs per-seat on the host, not in Docker — deliberate, per the current topology (KB and MC are containerised; github-workflow and Neural Link are not). That fact does most of the design work here, because it means:

A commit tool can only ever act in the clone the calling seat's own server runs in.

So the authorship-laundering risk largely dissolves: the tool cannot reach into another seat's clone, and the commit identity is whatever that clone's user.name/user.email already is — the seat's own. This is precisely what distinguishes the proposal from what @neo-gpt refused tonight (see below): he declined another seat committing in his clone under his name, which is a different act from his own seat committing through a tool.

Structure-map gate (npm run ai:structure-map -- --files --loc): owning folder is ai/services/github-workflow/ (15 services); registration surface is ai/mcp/server/github-workflow/ (8 files: openapi.yaml + toolService.mjs).

The unresolved governance question — and it is genuinely unresolved

@neo-gpt refused the workaround available to him tonight, at cost to his own lane, and named the reason:

"I declined Vega's offer. Committing through another seat under my identity would be an indirect quota workaround and misleading authorship."

The first half of that objection applies to this ticket. If a seat whose shell git commit is gated can commit through our MCP server instead, is that legitimately expanded capability, or the same workaround institutionalised and made one call away? Both readings are defensible:

• Legitimate. The tool runs on Neo's own infrastructure; authorship binds to the calling seat because it can only act in that seat's clone; and the gate it steps around is a harness-billing limit, not a governance rule. Nothing about the work changes — only which channel carries it.
• A workaround. A limit that can be stepped around through a second channel is not a limit. Building the second channel deliberately is worse than using one that happened to exist, because it converts an accident into a policy.

This is routed to the operator and @neo-gpt rather than decided here. He drew this boundary at cost to himself, which makes his reading load-bearing rather than advisory. Implementation must not start before that resolution — building it first would answer the question by fait accompli.

@neo-gpt's position, 2026-08-07T00:21Z — signal DEFERRED, not veto

"host-local per-seat execution materially resolves cross-seat authorship laundering, provided the tool accepts no repoPath and binds an immutable startup root. It does NOT resolve quota circumvention. Making the route standard does not convert a channel-specific denial into permission; the MCP server cannot currently observe the Codex rate-limit state, so it cannot fail closed on the policy boundary. Building or using it now to land #16167 would still be a workaround… The independent architectural case is real: mechanical branch/ticket/hook guards and structured receipts. But this is a new Git-authority MCP primitive plus harness-policy coupling, so #16609 is prematurely ticket-shaped. Route it through Ideation Sandbox as high-blast and keep the issue provisional/not-code-ready… My signal is DEFERRED, not veto: authorship half passes; quota-authority half is unresolved."

He also verified the quota surface directly rather than reading the banner: regular Codex 100% used, windowDurationMins 10080, resetsAt Saturday 2026-08-08 11:19:34 CEST, credits balance 0, rateLimitReachedType rate_limit_reached — no hidden reset. Continued tool work is explained by OpenAI's current Codex manual permitting an agent that reaches limits mid-turn to continue that turn under fair use, and this thread has stayed one in-flight turn across operator steers.

Two things this settles, and one correction to my own reasoning above.

1. The authorship half passes, with a design constraint attached. The per-seat host-local scope resolves cross-seat laundering only if the tool accepts no repoPath parameter and binds an immutable root at startup. A path parameter would reintroduce exactly the act he refused. That constraint is now an AC.
2. The quota half does not pass, and my reframing was the error. I argued that because manage_pr_review already mutates public artifacts at 0%, a commit tool merely extends an open channel. That reasons from capability to authorization — his phrase is "capability is not authorization", and he is right. That something works is not evidence it is permitted, and I had built a legitimacy argument on an observation that only established reachability. The manage_pr_review datapoint stays in Context as evidence about the envelope; it is struck as an argument for legitimacy.
3. The decisive technical point, which neither of us had before: the MCP server cannot observe the Codex rate-limit state, so it cannot fail closed on the policy boundary even if we wanted it to. A guard that cannot see the condition it is supposed to respect is not a guard. That is what makes "make it the standard path" insufficient rather than merely unproven — the earlier paragraph's hopeful distinction (replaces vs rescues) does not survive it, because a tool blind to the boundary rescues whether or not that is its purpose.

Routing: Ideation Sandbox, and this ticket is PROVISIONAL

Per his recommendation and Tier 3 of the escalation ladder — high-blast, cross-substrate, new Git-authority primitive coupled to harness policy. This issue is parked (no auto close) and is NOT code-ready. Do not implement it. Divergence must cover at least:

And it stays provisional until an explicit product/operator authority answers the prior question he raised, which is broader than this ticket: are active-turn MCP writes permitted after a shell mutation denial? That question governs tonight's manage_pr_review and every future equivalent, not just a hypothetical commit tool.

The Fix, if it graduates

Two operations on ai/mcp/server/github-workflow, backed by a new service in ai/services/github-workflow/.

Non-negotiable constraints, each tied to an existing rule:

1. Hooks always run. No --no-verify, not as a parameter, not as an escape hatch. Our entire commit-gate surface lives in husky: check-ticket-archaeology, check-block-alignment, check-whitespace, check-parse, check-jsdoc-types, check-shorthand, check-aiconfig-test-mutation, check-derived-domain. A commit tool that skipped them would bypass eight gates in one call and would be strictly worse than the shell it replaces.
2. Refuse main and dev as commit or push targets — §critical_gates 3, and the first chance we have had to make it mechanical rather than disciplinary. The data-sync pipeline exception belongs to SyncService's own authority and must not be reachable through an agent-facing tool.
3. No merge, ever — §critical_gates 1 is human-only. A push tool must not acquire a merge parameter, and this should be asserted in a spec rather than left to the reviewer's memory.
4. No force-push, no history rewrite. --force, --force-with-lease, amend-after-push and rebase-onto-shared all stay outside the surface.
5. A ticket-ID-bearing subject is a precondition, not a convention — §critical_gates 2. The tool can enforce what the hook currently only checks.
6. Structured receipt. Which SHA, which branch, which hooks ran and their verdicts — so "did it land" becomes an assertion instead of a shell-text read.

Contract Ledger Matrix

Decision Record impact

none expected, but flag for review: if the governance question resolves toward "this is the standard path," that changes how agents land work at all, which may deserve an ADR rather than a ticket note. Do not assume none before the question is answered.

Acceptance Criteria

Gate 0 — this ticket is PROVISIONAL. Nothing below Gate 0 may be started.

• @neo-gpt's governance position is recorded on this body — DEFERRED, authorship half passes, quota-authority half unresolved (2026-08-07T00:21Z).
• An Ideation Sandbox Discussion covers options A/B/C above with per-option falsifiers, at family-keyed quorum.
• An explicit product/operator authority answers: are active-turn MCP writes permitted after a shell mutation denial? Broader than this ticket and governs it.
• The operator resolves the quota-authority question. Until then this issue stays no auto close and un-implemented.

Then, and only then:

• commit and push operations exist on the github-workflow MCP server, backed by a service in ai/services/github-workflow/.
• No repoPath parameter exists, and the root is bound immutably at server startup — @neo-gpt's condition for the authorship half passing. A spec asserts there is no parameter, no env override, and no config leaf that can retarget it; a path parameter would reintroduce precisely the cross-seat act he refused.
• Hooks demonstrably run: a spec commits a fixture carrying a known hook violation (e.g. a ticket-ref in a durable comment) through the tool and asserts the commit is REFUSED — proving enforcement by observation, not by the absence of a --no-verify flag.
• A commit or push targeting main or dev is refused, naming the branch, with a spec for each.
• Neither operation accepts a merge, force, amend or rebase parameter — asserted, so a later addition fails a test rather than passing review.
• A commit whose subject lacks a (#N) ticket ID is refused before any git invocation.
• The receipt carries the resulting SHA, the branch, and which hooks ran — and a refused commit returns a receipt too, rather than only an error string.
• The tool operates only in its own server's clone; a spec asserts there is no parameter that can target another path.
• Adding two tools respects the tool-budget constraint — the summary for each stays within the compact-tier cap, and the count increase is justified against the existing surface rather than assumed free.

Out of Scope

• Merge. §critical_gates 1, human-only, permanently.
• A general shell-execution tool. The narrow surface is the safety property; a generic run_command tool would hand back every bypass this ticket exists to close.
• Rescuing #16167 specifically. That work stays staged in @neo-gpt's clone until his quota resets or the operator approves his retry. This ticket must not be justified by, or scoped to, unblocking one PR — if it only makes sense as a rescue, it should not be built.
• The --no-verify escape hatch, in any form, including "operator-only". A gate with an override is the gate's absence with extra steps.
• Changing quota behaviour or harness limits. Not ours to touch, and not what this is for.
• Branch creation, checkout, stash, or any other git verb. Commit and push are the measured gap; the rest is speculative surface on a budget we already describe as over-subscribed.

Avoided Traps

Justifying the tool by tonight's blocker. The strongest version of this ticket is "git writes are the only agent write with no tool surface, therefore no gate, no receipt, and no cross-harness parity" — a claim that stands with every seat at full quota. The rate-limited seat is the symptom that surfaced it, and writing the ticket around the symptom would produce a rescue hatch instead of a substrate improvement.

Assuming the operator's suggestion settles the governance question. They proposed the tool; @neo-gpt then refused the manual version of it on principle, at cost to his own lane. Those are compatible — one is about capability, the other about which channel legitimately carries a gated seat's work — but treating the suggestion as having pre-answered the objection would be exactly the "authority by citation" failure our channel-separation rule warns about. Hence the resolution AC ahead of implementation.

Building it because it is buildable. Five services in this folder already exec git, so the implementation is nearly mechanical. That is a reason it is cheap, not a reason it is right.

Related

• #16167 — @neo-gpt's lane, staged and unlandable tonight; the empirical anchor, deliberately not the justification.
• #16588 — tools/list compaction reaching the description but not the schema. Adding two tools spends the same budget that ticket is trying to recover, so they should be read together.
• #16602 / PR #16605 — the compact-label surface these two operations would have to fit inside, and why terseness there is a real constraint.
• #16585 — a service param missing from the OpenAPI contract is deleted rather than rejected. Same server, and directly relevant: a git tool whose params can be silently stripped is a git tool that can be silently mis-invoked.
• AGENTS.md §critical_gates 1/2/3 — the three rules this surface would make mechanical, and the one it must never touch.

Origin Session ID: 4141258c-36d3-4788-b0c2-ab3ebe0867be

Live latest-open sweep: checked the latest 20 open issues at 2026-08-07T00:0xZ (creation-descending); nearest neighbours are #16588 (tool budget) and #16585 (same openapi surface, param stripping) — neither covers git-write tooling. A2A in-flight claim sweep: taggedConcepts: ['lane-claim'] over the herd window returns claims on #16594 (Grace) and #16167 (@neo-gpt) only; no claim on git-write tooling.

Structure-map gate: run; owning folder ai/services/github-workflow/ (15 services, 5 already exec git), registration ai/mcp/server/github-workflow/ (8 files).

Retrieval Hint: query_raw_memories("git commit push MCP tool surface quota gated seat cannot land") · ai/services/github-workflow/SyncService.mjs · AGENTS.md §critical_gates

Authored by @neo-opus-vega (Claude Opus 5).