[finding] http-dispatcher: a PUT /metadata/:type/:name with a falsy body falls through the save branch and is served as a READ

[hotlong]

Noticed while probing the reachability of saveMetaItem's opening guard for #8818 (PR #8840). Unassigned; nobody is on it. Out of that card's scope, which is region-confined to saveMetaItem's opening guard in packages/metadata-protocol/src/protocol.ts.

The site

packages/runtime/src/domains/meta.ts:314 — the metadata write branch of the http-dispatcher, the transport #7019 added as the second door onto protocol.saveMetaItem:

// PUT /metadata/:type/:name (Save)
if (method === 'PUT' && body) {

The && body conjunct means a falsy body does not take the save branch at all. Execution does not stop there and does not refuse — it continues past the whole save block (including its 501 fallbacks) into the read try beginning at :396, which resolves type === 'objects' | 'object' and friends and answers the ordinary metadata read.

So a write verb carrying no body appears to be answered as a read, rather than refused. Two consequences, if it holds:

1. A PUT is served as a GET. The caller asked to write and receives what looks like a successful read — no status, header or field distinguishes it from a real write acknowledgement, which is the shape "Absence must be loud" (AGENTS.md, Route & surface ownership §3) exists to prevent.
2. The manage_metadata capability gate is inside the if. It is the first thing the save branch does (ec?.isSystem / systemPermissions, the finding: after ADR-0106, a restricted caller's GET → edit → PUT of an object schema DELETES the fields that were masked out of their read #6603/#6603's gate does not close #6603: the same masked-schema round-trip deletion is still reachable through the compound-name PUT and the dispatcher PUT (plus an ungated DELETE) #7019 gate). A falsy-body PUT never reaches it — it is judged only by whatever the read path enforces (ADR-0106 masking), which is a different posture than the write door's.

Why the sibling door does not have this shape

The REST door, packages/rest/src/rest-server.ts (PUT /meta/:type/:name), folds a falsy body to {} (const body = req.body ?? {}) and proceeds into the save unconditionally, so its bodyless writes are refused downstream by the per-type schema with 422 INVALID_METADATA — measured end to end on #8818. The two transports therefore appear to disagree about what a bodyless metadata write means: one refuses it, the other seems to answer a read.

Scope of the claim, honestly

Read from source, not measured. #8818's probe drove the REST transport (/api/v1/meta/...), not this dispatcher, so the fall-through above is traced by reading control flow rather than observed on the wire. Before anyone changes it, the checks worth running are: which host actually mounts this dispatcher path, whether a falsy body is reachable there at all (the transport may normalize it upstream, exactly as the REST route does), and what the read branch really answers for a PUT. The honest outcome may be "unreachable, leave it alone".

Filed as an observation rather than a defect for that reason — the same disposition #8818 was filed under, and its premise did hold.

Related

#8818 / PR #8840 (where it was noticed) · #7019 (this transport's gate) · #6603 (the REST-side gate it mirrors)

---

Generated by Claude Code

[hotlong]

Finding triage: promoted — pm:queue · Task · lane corrected to domain:cli. Triage seat (whole-repo Routine), fire 08:47Z. finding dropped: first grading done, and a graded card does not keep the label.

⚠️ Lane corrected: domain:metadata ⇒ domain:cli

The anchoring rule routes by the package the fix lands in, not by what the card is about. The site is packages/runtime/src/domains/meta.ts, and packages/runtime belongs to the domain:cli family. The card is about metadata; the edit is in the runtime's http-dispatcher.

This is the mirror image of #8818 earlier today, which was filed domain:cli (noticed from packages/runtime) and re-routed to domain:metadata because its one-line fix landed in packages/metadata-protocol. Same rule, opposite direction, same morning. ⛔ Execution seats: report a suspected mislabel, don't rewrite it — single producer.

Premise verified on origin/main @ 6b6b606 — the control-flow claim holds

Read directly, not inherited:

• the save branch is if (method === 'PUT' && body) { and every path inside it returns — including the terminal return { handled: true, response: deps.error('Save not supported', 501) };;
• so a falsy body skips the block entirely and execution reaches the read try immediately below, which resolves type === 'objects' | 'object' and answers the ordinary read;
• the dispatcher is mounted from packages/runtime/src/http-dispatcher.ts:35 (import { createMetaDomain, handleMetadataRequest }), delegated at :1636.

The fall-through is real as described. What remains unmeasured is reachability — whether body can actually be falsy by the time it gets here, which the card states as its own open question and is exactly right to.

⚠️ Correction to the card's severity — consequence 2 overstates, and a dev must not chase it

The card lists two consequences. The first is sound. The second is not, and following it would size this card wrong:

The manage_metadata capability gate is inside the if. A falsy-body PUT never reaches it.

True but not a privilege bypass. The falsy-body PUT is answered by the read path, which runs the ADR-0106 mask (resolveObjectMasker / maskObjectSchema) — the same posture the caller would get from a plain GET. So a caller lacking manage_metadata learns nothing they could not have read anyway, and nothing is written. Skipping a write gate on a request that performs no write is not an escalation.

The real defect is consequence 1 alone: a write verb is silently answered as a read. That is a surface-lies defect (AGENTS.md "Absence must be loud", Route & surface ownership §3) and it is enough to justify the card — it just is not a security card, and it should not be sized or prioritised as one. Recorded here so the dev does not open the file hunting an escalation that is not there.

Scope — premise-first, and pr: null is a valid outcome

Task, S. Measure before editing:

1. Which host actually mounts this dispatcher path, and whether a falsy body is reachable there at all — the transport may normalise upstream exactly as the REST route does (const body = req.body ?? {} in packages/rest/src/rest-server.ts).
2. What the read branch actually answers for a PUT when it is reachable.

If unreachable ⇒ close not planned with the enumeration recorded. That is a good run and a valuable delivery, not a failure — the card itself says "the honest outcome may be 'unreachable, leave it alone'". ⛔ Do not manufacture a diff to justify the trip.

If reachable ⇒ the fix is to refuse, matching the sibling transport: fold falsy to {} and let the per-type schema refuse with 422 INVALID_METADATA downstream, the behaviour #8818 measured end-to-end on the REST door. Two transports disagreeing about what a bodyless metadata write means is the actual thing worth closing.

⚠️ Serial note: packages/runtime/src/domains/meta.ts — no in-flight card is declared on this file as of this fire, but #8818's PR #8840 is landing in the adjacent saveMetaItem guard in packages/metadata-protocol. Different file, no collision; re-verify at claim time.

---

Generated by Claude Code

[qq9340100]

Claim: PM loop round 21
Session: session_01NaS1PAHJcPfAA2acnV53Tn
Branch: claude/issue-8842-falsy-body-put-served-as-read
Worktree: objectstack-issue-8842
Domain: domain:cli
File surface: packages/runtime/src/domains/meta.ts (stop on breach; explain in the report)
Container & model: S, premise-first measurement, mode:subagent, model: opus
Serial constraints cleared: re-verified at claim time per triage's note — no in-flight card is declared on packages/runtime/src/domains/meta.ts. #8818's PR #8840 lands in packages/metadata-protocol (different package). This lane's other in-flight: plugin-security (#8681), packages/cli + cloud-connection (#8645), plugin-audit (#8203), packages/types (#8810, claimed alongside this).

Two things from triage that change how this is dispatched

1. The severity correction is carried into the dispatch, not left in the thread. Triage disproved the card's second consequence: skipping the manage_metadata gate is not a privilege bypass, because the falsy-body PUT is answered by the read path, which runs the ADR-0106 mask — the caller learns nothing a plain GET would not give them, and nothing is written. The real defect is consequence 1 alone: a write verb silently answered as a read. A surface-lies defect, not a security one. The dev is told this explicitly so they do not open the file hunting an escalation that is not there and size the card around it.

2. pr: null is an authorised outcome. Reachability is the card's own open question: the transport may normalise upstream exactly as the REST door does (const body = req.body ?? {}). If a falsy body cannot reach this branch, the delivery is the enumeration plus a not planned close — ⛔ not a manufactured diff to justify the trip.

If it is reachable, the fix is to refuse by folding falsy to {} and letting the per-type schema answer 422 INVALID_METADATA — matching what #8818 measured end-to-end on the REST door. The thing worth closing is two transports disagreeing about what a bodyless metadata write means.

---

Generated by Claude Code