api passthrough bypasses the forge write guard #784

New issue

Closed

opened 2026-10-16 01:00:21 +00:00 by hexajon · 0 comments

hexajon commented

2026-10-16 01:00:21 +00:00

Owner

The forge write guard runs on the two first-class send paths only. The raw api passthrough sends its writes through a different path that never calls the guard, so a write through madtea api or madt_api_call reaches the forge with no check.

Reachable today:

DELETE /repos/<owner>/<repo>/issues/42 hard-deletes an issue, an omitted and unrecoverable destroy.
PUT /repos/<owner>/<repo>/contents/x {"branch":"main"} writes the default branch.
POST /repos/<other>/<repo>/contents {...} writes a repo outside the session scope.

Until the passthrough calls the guard, the endpoint-effect matcher is dead code in production and the "every surface" promise of the write-guard design is not met.

Fix:

Route every passthrough write through the guard before dispatch. Reads (GET, HEAD, OPTIONS) and pagination stay unguarded.
The guard matches on the api-relative path, so normalize an absolute or full-URL target to that path before the check, or the match silently returns no effect and the write is allowed.

Acceptance:

A passthrough write to the default branch, an omitted delete, and an out-of-scope content write are each refused.
A passthrough read is never refused.
A passthrough write sent in absolute mode is guarded too.

Part of the write-guard work (#670). Found while enabling the guard (#660).

The forge write guard runs on the two first-class send paths only. The raw `api` passthrough sends its writes through a different path that never calls the guard, so a write through `madtea api` or `madt_api_call` reaches the forge with no check. Reachable today: - `DELETE /repos/<owner>/<repo>/issues/42` hard-deletes an issue, an omitted and unrecoverable destroy. - `PUT /repos/<owner>/<repo>/contents/x {"branch":"main"}` writes the default branch. - `POST /repos/<other>/<repo>/contents {...}` writes a repo outside the session scope. Until the passthrough calls the guard, the endpoint-effect matcher is dead code in production and the "every surface" promise of the write-guard design is not met. Fix: - Route every passthrough write through the guard before dispatch. Reads (GET, HEAD, OPTIONS) and pagination stay unguarded. - The guard matches on the api-relative path, so normalize an absolute or full-URL target to that path before the check, or the match silently returns no effect and the write is allowed. Acceptance: - A passthrough write to the default branch, an omitted delete, and an out-of-scope content write are each refused. - A passthrough read is never refused. - A passthrough write sent in absolute mode is guarded too. Part of the write-guard work (#670). Found while enabling the guard (#660).

hexajon referenced this issue

2026-10-16 01:00:36 +00:00

add the write-guard parity test: no write around the guard #785

hexajon added a new dependency

2026-10-16 01:01:42 +00:00

#670 epic: one guard enforces the recorded limits on every surface

hexajon referenced this issue from a pull request that will close it,

2026-10-16 02:41:35 +00:00

feat(guard): enforce the ADR 0046 write guard on every forge write surface #790

hexajon referenced this issue from a commit

2026-10-16 02:41:35 +00:00

feat(guard): #660 enforce the ADR 0046 forge write guard on the first-class CLI and MCP surfaces