fix(relay): authorize send_message targets and surface egress declines (P5) - #99220
Merged
Merged
Conversation
P5 of the relay egress-authorization workstream. The relay path
authenticated the SENDER but never authorized the DESTINATION, and the
gateway compounded it from both ends.
(a) send_message could silently name an arbitrary relay target. Its
`target` parameter is free-form ('platform:chat_id'), so a model could
name ANY chat id and the gateway would emit an outbound frame for it.
gateway/relay/egress.py adds an attestation floor: a relay-routed
destination must have a provenance this gateway can show -- the
operator's home channel, the channel directory, or its own gateway
session origins. Anything else is refused HERE, with a visible tool
error naming the target, before a frame is written. Non-relay platforms
and platforms served by a live native adapter in this process are
untouched (same precedence resolve_delivery_transport applies).
(b) Connector declines were swallowed into apparent successes. The
connector's egress floor answers an unauthorized destination with a
DEFINITE failure whose text is deliberately uniform (F-005). Several
relay lanes degrade a *transport drop* by design and were degrading an
*authorization refusal* the same way:
- _send_media returned None, sending the caller into
BasePlatformAdapter's text fallback -- a DIFFERENT op re-addressed at
the very chat the connector had just refused.
- _send_prompt returned None, so exec-approval / slash-confirm /
clarify reported "relay prompt op unavailable" (a wrong reason) and
ran their numbered-text fallbacks into the refused chat.
- task_card_stop discarded the error entirely.
- typing / delete / react / thread ops degraded silently at debug.
is_egress_decline() classifies THAT a decline happened (never why --
the uniform text is not parsed for reasons) and requires a definite,
non-ambiguous failure, so a lost-ack retry is still a transport
outcome. Lanes with an error-carrying contract now report the decline
verbatim; cosmetic bool/None lanes still degrade but log it at WARNING.
Advisory progress drops that legitimately degrade are unchanged: the
task_card send lane, the draft ambiguous/except branches, and every
transport-exception path keep their existing fail-open behaviour.
Tests: 21 mutations of the production source, all KILLED.
Contributor
૮ >ﻌ< ა ci reviewran on e7cb5cf — fix(relay): invert the live probe to fail closed by default
|
alt-glitch
added
type/security
Review round 1 (independently confirmed by a second reviewer) found three blockers. Two are fixed here; the third (B-2, Telegram @username) is a policy decision left open deliberately. B-1 — THE FIX CAUSED THE OUTAGE IT PREVENTED (tools/send_message_tool.py) The P5(a) guard ran ABOVE Slack user->DM resolution, so it authorized the internal pseudo-id `_parse_target_ref` emits (`user_name:ben`, `user:U...`). Provenances only ever hold RESOLVED conversation ids, so a fully attested DM was compared as a handle against a set of `D...` ids and refused: base slack:@ben SENT head(before) slack:@ben REFUSED Every Slack DM by handle was broken. Moved the guard below resolution; it now authorizes the destination that is actually sent to, and the refusal names the resolved id. Position is load-bearing, so it is commented as such and pinned: reverting the move turns exactly the four new cases red. B-3 — A DECLINE IS NOT A LANE FAILURE (gateway/run.py) `_approval_send_outcome` had only sent/failed/ambiguous, so a connector decline collapsed into `failed` — which is the cue to run the plain-text fallback into the chat the connector had just refused. The adapter fix in the previous commit improved the error STRING while user-visible behaviour stayed identical to base; the commit message overstated it. Fixed properly: - new `declined` verdict, recognised via the shared `is_egress_decline` contract (not string sniffing at the call site) - exec-approval returns without the text fallback - slash-confirm suppresses the text reply AND clears the registration, so a card that never rendered cannot capture the user's next message `send_clarify` was already correct (returns early inside the adapter). MUTATIONS (production source; both directions) classifier never returns 'declined' -> KILLED (4 cases) ALL failures classified as 'declined' -> KILLED (2 cases) guard moved back above Slack resolution -> KILLED (4 cases) decline CODE changed (review M05) -> KILLED marker match made case-sensitive (M10) -> KILLED M05 was a tautology: the test asserted the imported constant against itself, so changing the constant could not fail it. The wire contract is now pinned as a literal, because the connector stamps that exact string and a one-sided change is a silent cross-repo break. REGRESSION CHECK: the 12 failures + 1 collection error in this test selection are PRE-EXISTING cross-test contamination — the identical set fails at 7cf8618. Verified by diffing the failing sets: no new failures, 363 -> 374 passed. NOT FIXED (deliberate): B-2, Telegram `@username`. The Bot API resolves handles at send time, so there is no id to compare and no canonicalization exists yet. That is a policy decision, not a code move.
andrexibiza
reviewed
Sep 1, 2026
andrexibiza
left a comment
andrexibiza
left a comment
Contributor
There was a problem hiding this comment.
Reviewed exact head be321faf278fb35b935d252f4bc0fc2b5b2c1759 against live main 180291162ff4df0d42b5dc4fecd08005cf7cebf9, the full 7-file diff, both surviving commits, exact-head workflow state, existing PR discussion/reviews, the active FILE-LIST around the relay/send boundaries, and the adjacent authorization/delivery work.
There is a lot of good work here. In particular, the PR correctly identifies that a definite authorization refusal is not interchangeable with a transport failure; the media regression proves the dangerous send_media -> send fallback shape with an exact op-count witness; the pending-prompt cleanup/converse test is the right state invariant; and moving P5(a) below Slack handle→DM resolution is the correct repair for the first-round outage. The first commit (7cf86188acb95ead7f83329aedd7f5ca47ea2593) also has successful CI/Docker/Nix receipts.
I do not think this exact head is merge-ready yet. I found two security-contract blockers plus current-main / ownership gates that need to be resolved before we can call P5 closed.
1. BLOCKER — the structured decline type is lost at the SendResult -> gateway.run boundary, so a contract-valid code-only decline falls back again
gateway/relay/egress.py::is_egress_decline() explicitly defines the structured code == "egress_declined" as the preferred signal. The new adapter code preserves the connector result in SendResult.raw_response=result when _send_prompt() returns a refusal. That is good.
But both new caller-side classifiers throw that type information away:
_approval_send_outcome()extracts onlyresult.error, reconstructs{"success": False, "error": _err}, and callsis_egress_decline()on that lossy dict._request_slash_confirm()does the same reconstruction frombutton_result.error.
That makes the supposedly typed refusal boundary depend on prose again.
There is a deterministic counterexample already admitted by this PR's own classifier contract:
connector_result = {"success": False, "code": "egress_declined"}is_egress_decline(connector_result) is True (and there is a test asserting exactly that). _send_prompt() therefore returns a failed SendResult with the original dict in raw_response; because there is no connector error string, decline_error() supplies the fallback text "relay egress declined". That fallback text intentionally does not match EGRESS_DECLINE_MARKER = "egress declined:" (note the colon). _approval_send_outcome() consequently returns failed, which is the cue to execute the plain-text fallback into the destination the connector just refused. Slash-confirm has the same loss.
So B-3 is fixed only for the current code+uniform-text combination, not for the contract that this PR itself declares. A connector can remain fully contract-conformant by preserving the structured code while omitting/changing the human text, and this gateway reopens the exfiltration path.
Required fix: carry the typed settlement through the boundary. The smallest coherent shape is to classify SendResult.raw_response first (including ambiguous) or to make the decline code/disposition a first-class SendResult field; do not synthesize a new dict from error text. Add an end-to-end regression that drives the real relay adapter into _approval_send_outcome and slash-confirm with {success: false, code: "egress_declined"} and no marker-bearing error, then asserts that no fallback send occurs. Please also pin the converse ambiguous case so a code/text-bearing lost-ack cannot be turned into a definite refusal.
2. BLOCKER — the model-facing authorization guard fails open on any guard fault
tools/send_message_tool.py::_authorize_relay_target() wraps both the import and the authorization call in except Exception, logs at DEBUG, and returns None. In this API, None means authorized.
That means any runtime defect in the security guard — not just an environment in which the gateway package is absent — converts P5(a) into no guard at all and proceeds to _send_to_platform. This is exactly the wrong failure polarity for a destination-authorization floor.
The rationale in the comment is narrower than the code: “missing gateway module means there is no relay egress.” If that compatibility case must exist, catch ImportError (or otherwise prove relay is unavailable) separately. Once the guard is present and invoked, an exception while deciding authority must not silently become permission. The inner egress helpers already deliberately degrade expected config/directory absence to empty provenance, so the broad outer Exception -> allow is not needed to support those normal cases.
Required regression: make gateway.relay.egress.authorize_relay_target raise and assert that a relay-routed send/react does not reach the platform send. This should be a visible refusal / typed tool error, not a DEBUG-only bypass.
3. BLOCKER — Telegram @username is an existing merged target contract, not an unowned policy question
The head commit explicitly leaves B-2 (telegram:@username) unresolved because there is no numeric id available at the comparison point. That is a real problem, but the repository has already made the product decision about the input shape: merged #53573 established telegram:@username as an explicit send_message target and carried the earlier #13274 approach forward; it also records #13535/#37572 as duplicate lineage. Current main still contains the Telegram username target parser/normalizer.
P5(a) now compares the supplied destination string against home/directory/session provenance. Relay-fronted Telegram sessions normally attest numeric chat ids; a valid public-channel @username therefore cannot prove equality to the numeric destination it names unless the exact username happens to be present as a separate provenance. That narrows an already-merged tool contract only on the relay route.
Please do not solve this by bypassing authorization for usernames. The missing operation is resolution plus proof binding: resolve the handle to the actual connector/Bot-API destination (or obtain an equivalent connector-owned attestation), then authorize the exact object that will be mutated. Add positive coverage for an attested public-channel username and negative coverage for an unresolvable/unattested handle. If the repository intentionally wants to revoke relay-fronted @username support, that needs to be an explicit contract change with docs/tests and the prior lineage acknowledged, not an implicit P5 side effect.
4. Current-main / ownership gate — this head is 588 commits behind and its FILE-LIST is not clean
Live comparison is currently:
main:180291162ff4df0d42b5dc4fecd08005cf7cebf9- reviewed head:
be321faf278fb35b935d252f4bc0fc2b5b2c1759 - merge base:
a9c783f21995723c812dcb2f8ae58bc6a4323e2f - topology: 2 ahead / 588 behind
That is too much live repository movement for security acceptance to transfer from the branch's local/base comparisons. There are also active direct owners on the same files:
- #99736 changes both
gateway/run.pyandgateway/relay/adapter.pyfor relay dormancy/redial ordering and was updated again today. - #93154 changes
gateway/relay/adapter.pyspecifically around relay interactive/clarify behavior. - #74113 changes
gateway/relay/adapter.py::_send_promptfor relay-fronted cron clarify routing. - #91792 changes
gateway/relay/adapter.pythread creation/seed behavior. - #98445 changes
gateway/run.pyfallback/notification send semantics. - #81554 changes
tools/send_message_tool.pyand the broader egress boundary. It is complementary, not a duplicate: that PR is primarily whole-payload/secret egress guarding and durability, while this PR is destination authorization + refusal settlement. The two still share a model-facing send boundary and must not independently own incompatible interception order.
Please rematerialize/rebase on current main, reconcile those owners explicitly, and rerun the exact object after composition. Preserve their contributor lineage rather than flattening adjacent work into P5.
There is also a structural merge gate in the submitted shape: this PR adds production logic at gateway/run.py hunk ~25,199 and gateway/relay/adapter.py hunk ~3,493. Both modified files are already well past the repository's sub-2K ceiling. New authority/settlement logic should land through bounded owners/extractions rather than growing the godfiles further; the active FILE-LIST above makes that coordination even more important.
Exact-head CI state
At the time of this review, the reviewed head has:
- Nix flake check
33567813129: success - Docker Build/Test
33567813288: success - repository
CI: no exact-head run/check present yet (the check-run set for this SHA contains Docker/Nix only)
The parent commit's CI/Docker/Nix are green, but every surviving commit needs its own complete repository acceptance. Do not transfer the parent CI receipt to this head.
Interlock / defect-class disposition
This PR is not a duplicate of the relay transport-result work in #82238; that work establishes that dead-socket/outbound failures settle as result objects rather than exceptions, while P5 is assigning an authorization disposition to one definite failure class. They compose, and the ambiguous distinction here is the correct side of that boundary.
Likewise #72008/#57358 are useful mirror classes, not substitutes: they bind relay inbound prompt/platform authority to the correct owner/fronted identity; P5 is the outbound half, binding a mutation to an attested destination. The important invariant across both sides is the same: identity/authorization proof has to survive every projection layer until the exact mutation or settlement decision; it cannot collapse into ambient state or prose halfway through.
Once the three behavior blockers are fixed on current main, the godfile/FILE-LIST ownership is reconciled, and the exact rematerialized commit has full green CI/Docker/Nix, this is a strong security slice. The empirical lane enumeration and the refusal-vs-transport distinction are worth keeping exactly as hard as they are now.
Third independent review. Two more blockers, both reproduced before fixing.
1. THE GUARD ITSELF FAILED OPEN (tools/send_message_tool.py:158)
`_authorize_relay_target` wrapped BOTH the import and the call in one
`except Exception: return None` — and None means AUTHORIZED at every call site.
So any runtime bug inside the guard silently switched the entire P5(a) boundary
off. Reproduced: with the guard raising, an unattested target sent.
The docstring already stated the correct intent ("must not fail closed on its
own IMPORT error") and the code did something broader. The two failures are not
the same: a missing gateway package means there is no relay egress to
authorize; a fault inside the guard means authorization did not happen. The
import is tolerated, the call is not — a guard that cannot answer refuses.
2. THE STRUCTURED DECLINE WAS THROWN AWAY (gateway/run.py)
The adapter preserves the connector's dict in `SendResult.raw_response`. My
previous commit rebuilt a dict from the error STRING, which loses two
contracts:
* a decline carrying `code: egress_declined` and NO text renders as
"relay egress declined" — no marker colon — so it classified as `failed`,
which is exactly the cue to run the fallback into the refused chat;
* `ambiguous: True` (lost ack) was flattened into a DEFINITE failure,
re-sending a card that may already be on the user's screen. That is the
duplicate-card bug the ambiguous verdict exists to prevent, reintroduced
by the fix meant to harden the same path.
Both call sites now classify `raw_response` when present, ambiguity first, and
fall back to the wire sentence only for connectors that send no structured
response.
I had fixed the text-marker path and tested only the text-marker path. Worth
naming: the review's probe was a shape my tests never produced.
MUTATIONS (production source)
guard fault returns None (fail open again) -> KILLED
classifier ignores raw_response -> KILLED (3 cases)
ambiguous treated as a definite failure -> KILLED (2 cases)
40 focused tests pass. Regression check vs be321fa: identical 13-item
failing set (pre-existing cross-test contamination), no new failures.
STILL OPEN: B-2 / finding 3, Telegram `@username`. The reviewer is right that
this is a REGRESSION of an existing contract (#53573 added Bot API username
support), not merely an unspecified input, since relay provenance stores the
numeric chat id. Fixing it means resolving the handle before authorization, or
explicitly revoking the contract. That is a policy decision, not a code move,
and it is Ben's call.
…m load-bearing Round-2 review reported six unpinned survivors from round 1. Two guard real behaviour and are now covered; the other four are cosmetic-lane warnings and fail-open branches I am leaving documented rather than pretending to close. M25 — thread-qualified session ids. `_session_ids` adds BOTH "chat:thread" and the bare chat, because the connector authorizes the CHAT. Without the split a gateway whose session origin is `-100999:77` cannot send to `-100999`, the chat it is demonstrably already talking in. KILLED. M21 — the generic `relay` plane must union every fronted platform, since a relay session is filed under its LOGICAL platform. KILLED. MY FIRST M21 TEST WAS THE DEFECT IT WAS TESTING FOR. I patched `_relay_fronted` — the very function the mutation empties — so emptying it changed nothing the test could see, and the mutation SURVIVED against a green test. Rewritten to drive the real `relay_fronted_platforms()` through its env source (`GATEWAY_RELAY_PLATFORMS`), which is how production learns it. That is the same "the test verifies my stand-in" failure I have spent this workstream removing from the connector harnesses, reproduced here in three lines of Python. The tell was identical: a mutation that survives a test written specifically to kill it. 334 tests pass. NOT PINNED, deliberately: M03 (success-guard on a malformed dict), M24 (empty-target allowance — the one fail-open branch, reachable only when the bare-platform path already resolved a home channel), M35/M36 (decline WARNINGs on cosmetic lanes). All four are observability or defence-in-depth rather than authorization, and the review agrees they are non-blocking.
…B-2) Closes the last blocker. Two reviewers independently called this a REGRESSION of the public-channel username support added in #53573, not an unspecified input, and they were right: provenance stores RESOLVED numeric chat ids, so comparing `@channel` against them could only ever refuse. WHY THE GATEWAY CANNOT ANSWER IT. The guard fires only when there is no live native adapter — i.e. relay-fronted deployments — and on exactly those the CONNECTOR holds the bot token, not this process. There is no local way to turn a handle into the numeric id. Refusing here is not "fail closed", it is "fail always". WHY DEFERRING IS SAFE. The destination is still authorized one layer out: the connector's Telegram egress floor (gg#238, merged 743a7c2) classifies and refuses unauthorized destinations after ITS resolution — the layer that closed the reported vulnerability in the first place. Handles go from two guards to one, the authoritative one, not to zero. The carve-out is deliberately narrow and its EDGES are pinned, because the failure mode of an exemption is silent widening: telegram `@handle` -> deferred (the regression case) telegram numeric id -> still guarded matrix `@user:server` -> still guarded (telegram-only) bare name, no `@` -> still guarded attested handle -> normal path, attestation still consulted MUTATIONS carve-out widened to all platforms -> KILLED carve-out widened to every target -> KILLED carve-out removed (regression back) -> KILLED carve-out checked BEFORE attestation -> KILLED THE ORDERING MUTANT SURVIVED MY FIRST TEST. Both orderings return None, so asserting the verdict could not tell them apart — the test asserted the claim instead of the mechanism. Rewritten to observe that attestation is actually consulted. Same defect class as the M21 test earlier in this branch: a mutation surviving a test written specifically to kill it means the test is measuring the wrong thing. 341 tests pass. FOLLOW-UP (option 2, Ben's call, deliberately NOT done here): resolve the handle before authorizing so BOTH layers apply. That needs a resolution round-trip through the connector — new wire surface — so it belongs in its own phase rather than bolted onto this one. Recorded in the code comment at the carve-out, not just here.
Contributor
Author
|
Sequencing note: this PR does not close the Telegram The handle carve-out here ( The connector's tenant resolver keys the routing table on The connector-side fix is NousResearch/gateway-gateway#254, which canonicalizes Merge order: gg#254 first. Nothing here is wrong or unsafe without it — the other blockers this PR closes (Slack pseudo-id resolution ordering, connector declines no longer running text fallbacks, the guard's own fail-open, structured/ambiguous decline classification) are independent and complete. But do not read this PR as making Telegram handles work end to end. |
5,290 commits behind, and `main` decomposed every file this PR touches, so
three of the four conflicts were structural rather than semantic. Resolved by
taking main's structure and re-homing the P5 changes into it — never by
picking a side, which would have dropped either the refactor or the fix.
WHERE THE WORK MOVED
tools/send_message_tool.py 2499 -> 590 lines (split into
send_message_targets/senders). The guard
function and BOTH call sites re-inserted.
The send-path call keeps its documented
position BELOW Slack user->DM resolution —
main kept that resolver, so the constraint
that caused the first-round outage still
holds.
gateway/run.py 33682 -> 5510 lines. _approval_send_outcome
stayed; its `declined` verdict re-applied.
_request_slash_confirm run.py -> gateway/run_busy.py
exec-approval outcome consumer run.py -> gateway/run_turn_runner.py
ADAPTER: THE FIX IS NOW SMALLER THAN THE ONE IT REPLACES
main introduced `_gated_op`, a shared helper that centralises what P5 had
patched into ten call sites. Rather than reinstate ten hand-edits, the
authorization distinction now lives in the helper: every lane LOGS a decline,
and the two lanes whose fallback would leak (`_send_media`, `_send_prompt`)
opt into surfacing it via `surface_declines=True`.
CRITICALLY, MAIN STILL HAD THE LEAK. `_send_media` on main returns None on a
decline and its own comment says the caller's fallback "still delivers the
caption/notice" — a DIFFERENT op against the SAME chat the connector just
refused. The merge does not make this fix redundant; it re-expresses it.
Also fixed while merging, both caught by the suite rather than by reading:
* `_outbound` is a SECOND frame path (typing, delete, thread create/rename)
that bypasses `_gated_op` entirely — a refusal there vanished from the
logs. Return contract unchanged; the decline is recorded.
* the pending-prompt teardown fired only on None, so a decline (now a failed
SendResult) leaked a registration — a card that never rendered could
capture the user's next unrelated message as its answer.
* task_card_stop dropped the connector's `error`, reporting a refusal as a
bare failure.
MUTATIONS, re-run on the merged tree — a clean merge is not proof:
media decline degrades to None (the leak) KILLED
guard fault -> authorized (fail-open) KILLED
`declined` verdict never returned KILLED
pending prompt not torn down on decline KILLED
392 passed across tests/gateway/relay + the send_message and decline suites,
zero failures.
…e for real
Both blockers from review, each REPRODUCED before fixing.
1. STRUCTURED DECLINE HAD NO GUARD. Deleting `raw_response=result` from both
`_send_prompt` return branches left all 34 tests green — a surviving,
non-equivalent security mutant. The `code` field is the documented
PREFERRED signal precisely because a connector may send no prose, and a
caller rebuilding `{"success": False, "error": ...}` cannot see it.
Cause: every existing case declines with marker TEXT. The evidence for the
code-only path was a hand-built SimpleNamespace in a different file — a
stand-in for the adapter, so it verified my fixture instead of production.
Fixed with a CodeOnlyDecliningConnector driving the real
`send_exec_approval` -> `_send_prompt`, feeding the REAL SendResult to the
REAL `_approval_send_outcome`, plus the same shape on the media lane.
drop raw_response SURVIVED (34 passed) -> KILLED
2. TWO FAIL-OPEN BOUNDARIES, both "absence" and "fault" sharing a return.
`_relay_fronted` swallowed EVERY exception and returned an empty set, which
`relay_routed_platform` reads as "not relay-routed" — skipping the guard.
Probe, with a positive control in the same run:
positive_control_denied = True
discovery_fault_denied = False <- unattested target AUTHORIZED
`_authorize_relay_target` caught every exception during IMPORT as "no
gateway package". A module that exists and fails to initialize is a fault,
not an absence, and returning None there means authorized.
Now: ImportError alone is absence; anything else raises RelayRouteUnknown
and `authorize_relay_target` converts it to a REFUSAL STRING (not a raised
exception — every caller treats the return value as the verdict, so raising
would trade a fail-open for a crash).
Kept the converse under test so "fail closed" does not silently become
"refuse everything in CLI/cron", which is the outage the broad except
existed to prevent.
discovery fault -> empty set KILLED
RelayRouteUnknown -> authorized KILLED
import fault -> authorized KILLED
397 passed (was 392, +5 new cases), zero failures.
Every finding reproduced before fixing; every fix mutation-checked after. CONTENT LEAKS (the decline was laundered into a different op, same chat) #1 A declined DRAFT SEAL replayed as a plain send. On stream-is-the-message platforms the turn-final becomes draft(final=True); `_seal_open_draft` dropped the structured body, so `_absorb_into_open_draft` read a REFUSAL as a lane failure and fell through. Probe, Slack descriptor: before: draft(partial) -> draft(final,SECRET) -> send(SECRET) after: draft(partial) -> draft(final,SECRET) My first probe of this used a discord descriptor and showed no seal at all — the leak is real, my probe was wrong (streams only arm for Slack). #6 Task-card PROGRESS had the same defect one lane over: a bare failed SendResult reads as "card lane unavailable", and TurnRunner then sends the task text to the same chat. Both card methods now carry raw_response and the caller suppresses the fallback on a decline. AUTHORIZATION BYPASSES #2 `except ImportError` was NOT the fix I claimed last round. ImportError also covers a broken dependency inside an INSTALLED gateway; review probed `ImportError.name = "gateway.relay.dependency"` and got an authorized verdict. Now only a name identifying the gateway relay module itself is absence. An ImportError with NO name stays absence — refusing on a fault we cannot attribute would trade an unidentifiable bug for a real CLI/cron outage, and an existing test caught exactly that when I first got it wrong. #3 `relay_routed_platform` lowercases the requested platform; `_relay_fronted` returned configured names verbatim. A platform configured as "Discord" missed the membership test, looked native, and skipped the guard: 'discord' => refused 'Discord' => ALLOWED 'DISCORD' => ALLOWED An attestation bypass on a string comparison. UNDELIVERABLE PROMPTS THAT HUNG #4 `_clarify_send_disposition` handled `failed` and `ambiguous` but not `declined`, so a REFUSED clarify card fell through to wait_for_response and blocked until clarify_timeout — indefinitely when configured non-positive. A decline is more definitive than a failure, not less. #5 The exec-approval decline branch returned quietly, which suppressed the text fallback (right) but left the CENTRAL approval entry pending (wrong) — the dangerous command stayed blocked until the approval timeout. My comment claimed the registration was torn down; only RelayAdapter's private map was. It now raises `_ExecApprovalDeclined`, which propagates to `_await_gateway_decision`'s existing notify-failure path (drops the entry, unblocks the tool). A dedicated type, re-raised past the local `except Exception` that would otherwise have restored the leak. #7 THE GAP THAT LET ALL OF THIS SHIP. Both caller-level suppressions were unfalsifiable: deleting either branch left 36/38 tests green. The suites drove `_approval_send_outcome` and `RelayAdapter` but never the real TurnRunner / busy-session callers, so nothing observed whether a text send FOLLOWED a decline — which is the whole property. tests/gateway/test_decline_fallback_suppression.py drives both real callers and records every send. Each decline case is paired with an ordinary-FAILURE control, because without one a caller that never falls back would also pass. MUTATIONS (all on production source, anchors count-checked, restored after) #1 seal decline -> plain send KILLED #1b seal drops raw_response KILLED #2 nested ImportError -> authorized KILLED #3 fronted set not normalized KILLED #4 clarify declined branch removed KILLED #5 approval decline returns not raises KILLED #6 task_card drops raw_response KILLED #7 slash-confirm suppression removed KILLED #7's two were the reviewer's SURVIVORS (36/38 passing); both now die. 425 passed, zero failures.
Round 4 confirmed six of seven round-3 fixes and found three more. Each
reproduced before fixing, each mutation-checked after.
1. A NAMELESS ImportError still authorized. Last round I admitted it as
"absence" to protect the CLI/cron path. That reasoning was WRONG and the
interpreter says so:
import gateway.relay.nope -> ModuleNotFoundError, name="gateway.relay.nope"
import totally_absent_pkg -> ModuleNotFoundError, name="totally_absent_pkg"
Genuine absence is ALWAYS ModuleNotFoundError with `.name` set, so the
CLI/cron path never produces a bare ImportError and nothing legitimate was
being protected. A plain or nameless ImportError comes from an import hook
or a module that failed while initializing — an unattributable FAULT.
Now: absence is ModuleNotFoundError naming gateway / gateway.relay /
gateway.relay.egress; everything else refuses. Two existing tests raised a
bare ImportError to simulate absence and were corrected to the real shape.
2. SESSION ATTESTATION INVENTED IDS. `_session_ids` split every id on the first
colon to recover "chat" from "chat:thread". Matrix ids contain a colon
natively, so `!room:server.org` attested a bare `!room` — the guard
vouching for a destination on its own fabrication. The split now applies
only to platforms whose ids genuinely carry a `:thread` suffix (allow-list;
unknown platforms are treated as un-splittable, which can only refuse more).
Kept a Slack control: dropping the split entirely would refuse legitimate
thread replies, which is the outage the split exists to prevent.
3. THE TASK-CARD FIX WAS UNFALSIFIABLE — my own round-3 mistake, and the same
one round 3 caught me making. I added the production branch AND a test, but
the test stopped at RelayAdapter: it proved `raw_response` is carried and
never called `TurnRunner._task_card_publish`, which owns the property.
Deleting the real branch left 30 tests green. Now driven through the real
caller, with an ordinary-failure control.
The lesson generalises: proving the DATA reaches the boundary is not proving
the CALLER acts on it. Every one of these decline fixes has two halves and
the second half is where the security lives.
Also closed the round-4 non-blocking finding: `gateway/relay/egress.py` has its
OWN import boundary, and the existing test intercepted the earlier import in
tools/send_message_tool.py, so it was never exercised. Mutating that classifier
to treat every ImportError as absence now dies.
MUTATIONS (production source, anchors count-checked, restored after)
R4-1 nameless ImportError -> authorized KILLED
R4-2 session split unconditional KILLED
R4-3 task-card caller branch removed KILLED (was SURVIVED)
egress classifier: any ImportError = absence KILLED
Also probed and found NOT a leak: a refused OPENING draft frame disarms the
stream and the turn-final goes out via `send`. That send is itself guarded and
the connector refuses it too, so no content is delivered — unlike the seal case
(round 3, #1) where the seal was the only check on that path.
452 passed, zero failures.
Round 4 blocker 2 was closed with an allow-list of platforms whose ids have no
native colon. Reviewing my own fix while round 5 ran, the allow-list is the
wrong mechanism: it NARROWS a guess instead of removing it, and it still gets
Matrix wrong the moment a Matrix session is thread-qualified
(`!room:server.org:$thr` -> split yields `!room`).
The structured field was there all along. `_session_entry_id` composes the id
as f"{chat_id}:{thread_id}" and the entry still carries `thread_id`
separately, so the parent is knowable EXACTLY: strip the known suffix, or add
nothing. No platform list, no guessing, correct for ids that contain colons.
Mutations:
back to splitting on the first colon KILLED
thread parent never recovered (over-refuse) KILLED
Both directions matter: the first invents attestations, the second refuses
legitimate thread replies.
One existing test (M25) asserted the right PROPERTY with a fixture that omitted
`thread_id` — a shape real entries never have. Fixture corrected, assertions
untouched.
453 passed.
Each reproduced before fixing, each mutation-checked after.
R5-1 A DISABLED NATIVE ADAPTER BYPASSED AUTHORIZATION. `_has_live_native_adapter`
treated any entry in the adapter map as native; `resolve_delivery_transport`
ignores a native adapter whose config is disabled and routes over Relay.
Two independent routing classifiers, disagreeing:
guard says native: True delivery routes relay: True
So the guard skipped authorization for a send that went over the relay.
The guard now applies the router's enabled-state rule; probed both
configurations and they agree.
R5-2 THREAD IDS WERE NEVER AUTHORIZED. The parser splits chat_id and thread_id;
only chat_id reached the guard. On Discord the thread IS the destination —
`POST /channels/{thread_id}/messages` — so an attested parent channel
authorized an arbitrary caller-supplied thread. `authorize_relay_target`
now takes thread_id and requires its own attestation (bare id or the
`chat:thread` form a session origin produces); both call sites forward it.
R5-3 A DECLINED **INITIAL** DRAFT WAS RETRIED AS A PLAIN SEND. Round 3 fixed the
declined SEAL; the declined OPEN was a different path. `send_draft`
returned a bare failure, so the stream consumer read "draft transport
unusable", disabled drafts and fell through to `_first_send`. Measured
through the real adapter and real StreamTransportMixin:
before: ops ['draft', 'send'] after: ops ['draft']
send_draft now carries raw_response; a decline is terminal for the run and
the guard sits in `_first_send`, where every fallback path converges.
R5-4 MY ROUND-4 TASK-CARD FIX SUPPRESSED EXACTLY ONE UPDATE. It set
`native_failed`, which the entry gate already uses for an ordinary broken
lane, so the next progress event skipped the decline branch and went
straight to the text fallback:
after first publish: [] after second: ['send']
Terminal declines are now a separate `egress_declined` state checked at the
entry gate. A refusal does not expire after one tick.
MUTATIONS
R5-1 disabled native counts as native KILLED
R5-2 thread_id not authorized KILLED
R5-2b tool does not forward thread_id KILLED (was SURVIVED)
R5-3 initial-draft decline not terminal KILLED
R5-3b _first_send guard removed KILLED
R5-4 declined state not persistent KILLED
R5-2b is the same gap that produced findings 3 and 4 of the last two rounds, a
third time: every test called `authorize_relay_target` directly, so dropping the
argument from the TOOL WRAPPER changed nothing. Testing the callee never proves
the caller uses it — now pinned explicitly.
Each fix ships with an ordinary-failure control, because every one of these
makes the guard refuse MORE, and over-refusal is now the larger risk.
474 passed, zero failures.
Both terminal-decline flags were set dynamically. They worked (neither class is frozen or slotted) but an undeclared attribute hides the state from anyone reading the class, and this one is security-relevant. _TaskCardState.egress_declined — declared dataclass field StreamConsumer._egress_declined — initialised in __init__ Lifetime verified while checking whether a refusal can leak ACROSS turns and mute a healthy destination: it cannot. _TaskCardState is constructed per progress-drain (run_turn_runner.py:420) and the consumer's flags per run (stream_consumer.py:163), so both are fresh each turn. Also verified the guard's blast radius after adding thread authorization: the ONLY callers of authorize_relay_target are the two model-facing send_message call sites. Gateway-internal sends — notably the handoff path, which creates a thread and immediately posts to it with no session provenance yet — go through transport.adapter directly and are unaffected. That was the most plausible over-refusal, and it does not reach this guard. 461 passed.
R6-1 MY OWN R5-1 FIX REINTRODUCED THE BYPASS IT CLOSED. I wrote
`except Exception: return True` around the config lookup, so a config read
fault declared the platform native while the ROUTER, reading the real
config, sends over the relay:
guard_has_live_native True guard_verdict None router relay
Routing we cannot determine is UNKNOWN. It now raises RelayRouteUnknown,
which the outer handler must re-raise rather than flatten to False, and
`authorize_relay_target` turns into a refusal. This is the second time a
convenience `except` in this function created a bypass; there is now no
permissive return left in it.
R6-2/3/4 THE NINTH LANE: `edit`. ONE dropped field, THREE leaks.
`RelayAdapter.edit_message` discarded the connector response, and three
independent callers read a bare edit failure as "editing is unavailable"
and re-send the content as a NEW message to the same chat:
stream edit fallback ['edit', 'edit', 'send'] the unseen tail
queued reconciliation ['edit', 'send'] the WHOLE response
task-card fallback ['edit', 'send'] the task text again
Fixed at the source (edit_message carries raw_response) plus each caller:
`_on_edit_failure` — the single funnel for stream edit failures — makes a
decline terminal for the run, `_send_fallback_final` refuses to deliver a
continuation after one, the queued reconciler returns instead of sending,
and the task-card fallback sets the same terminal state R5-4 introduced.
R5-4 fixed the native task-card op and I did not check its sibling
fallback path. The pattern across rounds 3-6 is consistent: the fix goes
where the decline is OBSERVED, and the leak lives wherever someone else
later decides to retry.
MUTATIONS
R6-1 config fault -> assume native KILLED
R6-1b RelayRouteUnknown swallowed as False KILLED
R6-2 edit drops raw_response KILLED
R6-2b edit-failure decline not terminal KILLED
R6-3 queued reconcile falls back on decline KILLED
R6-4 task-card fallback edit decline KILLED
Each with an ordinary-failure control: a genuinely un-editable message must
still be delivered, and a broken card lane must still reach the user.
481 passed, zero failures.
THE STRUCTURAL FIX, not a twelfth local check.
Rounds 3-6 of review found ONE defect in eleven lanes: the connector refuses an
op, and some caller downstream reads that as 'this lane is unavailable' and
retries the same content through a DIFFERENT op against the SAME chat. Media,
prompt, draft-open, draft-seal, native task card, task-card fallback edit,
slash-confirm, exec-approval, clarify, stream edit, queued reconciliation.
Each was closed by adding a check at one more call site. That approach cannot
converge: gateway/ has ~60 outbound call sites, every one of them a place a
future change can reintroduce this, and four consecutive review rounds each
found another. The reviewer's own count of lanes is the argument against the
per-site design.
Every relay frame from every one of those callers passes through
_transport.send_outbound. One latch there covers them all: once the connector
refuses a chat, this adapter stops emitting CONTENT frames for that chat.
Proven to subsume the local checks: with the stream-edit per-site check
DISABLED, the leak probe still reports blocked=true — the frame never reaches
the wire. The local checks stay as defence in depth and for their better error
messages, but they are no longer the only thing standing between a decline and
a re-addressed send.
Scope is deliberately narrow, and each limit is mutation-pinned:
per CHAT - a refusal must not mute other conversations
CONTENT ops - typing/delete carry nothing; latching them would leave a
stuck typing indicator for no security gain
self-healing - cleared when the connector accepts that chat again, so a
transient policy change does not need a restart
Mutations:
latch never set KILLED
latch never consulted KILLED
latch is global, not per-chat KILLED
latch never clears KILLED
485 passed.
Round 7 reviewed 573e41e — one commit BEFORE the terminal-decline latch — and independently reached the same conclusion I had: 'The per-call-site approach is structurally wrong. Use one turn-scoped choke point.' That is the latch in 6dbc004. Its four 'still broken' lanes (tool-progress edit, progress-overflow edit, long-running heartbeat edit, stale streamed-final reconciliation) all share the shape edit_message->declined->adapter.send(same chat, same content), and NONE has a local check. Probed all four against the latch: tool_progress ops ['edit'] blocked progress_overflow ops ['edit'] blocked heartbeat ops ['edit'] blocked stale_final ops ['edit'] blocked That is the argument for the choke point, measured: lanes nobody patched are safe anyway. Pinned by a parametrized test named for those four lanes. R7-1 IS A REAL BYPASS THE LATCH DOES NOT COVER, and it is fixed here. The guard rebuilt routing from GATEWAY_RELAY_PLATFORMS while resolve_delivery_transport asks the CONNECTED adapter (fronts_platform, from the handshake identity set). Different snapshots: with env discovery stale or momentarily empty, the guard said 'native' and the router sent over the relay, skipping authorization. before: guard_relay_routed False / delivery relay after: guard_relay_routed True / delivery relay / unattested target refused The guard now asks the live adapter first and falls back to config only when there is no runner (CLI/cron) — pinned in both directions. R7-5 (non-blocking, and a fair hit): my stream-fallback test asserted _egress_declined and never drove _send_fallback_final, so removing that early return SURVIVED. The test now calls the real fallback and asserts the wire is untouched; the mutation dies. Mutations: R7-1 guard ignores the live adapter KILLED (was SURVIVED) R7-5 fallback early return removed KILLED (was SURVIVED) latch not consulted KILLED 491 passed.
Round 8's brief told the reviewer to attack the latch. I did the same in
parallel and found three real holes in it before the review returned.
1. send_for_platform BYPASSED THE LATCH ENTIRELY. It builds and posts its frame
directly rather than through _outbound — and it is the delivery resolver's
OWN entry point, so it is the single most important caller.
before: ops ['edit', 'send'] after: ops ['edit']
gateway/AGENTS.md states the rule I had just broken: 'Seal-interception
exists at BOTH egress doors (send() and send_for_platform()); a new egress
door needs the same two checks.' The latch is a third such check and I had
wired it to one door.
2. A COSMETIC SUCCESS CLEARED THE LATCH. Clearing on ANY success meant a
typing indicator — routinely allowed for a chat whose content is refused —
re-opened the door for the very next send:
ops ['edit', 'typing', 'send']
Only a CONTENT op the connector accepted may clear it now.
3. A THREAD INSIDE A REFUSED CHAT WAS NOT COVERED. A thread lives inside its
parent, so the same content reached the same conversation one level down:
ops ['edit', 'send']
The latch key now strips the thread suffix.
Also normalised int/str chat ids (callers pass both; a type mismatch would
silently unlatch).
MUTATIONS
send_for_platform not latched KILLED
cosmetic success clears the latch KILLED
thread suffix not stripped KILLED
draft-seal retry not latched SURVIVED — EQUIVALENT, proven:
is unreachable while latched (a declined edit before the seal
produces ZERO seal frames, measured). Kept as defence in depth because it
posts directly, and documented at the site rather than covered by a
test that could not fail.
One self-inflicted bug on the way: a blanket replace put 1Password CLI brings 1Password to your terminal.
Turn on the 1Password app integration and sign in to get started. Run
'op signin --help' to learn more.
For more help, read our documentation:
https://www.1password.dev/cli
1Password CLI is built using open-source software. View our credits and
licenses:
https://downloads.1password.com/op/credits/stable/credits.html
Usage: op [command] [flags]
Management Commands:
account Manage your locally configured 1Password accounts
connect Manage Connect server instances and tokens in your 1Password account
document Perform CRUD operations on Document items in your vaults
events-api Manage Events API integrations in your 1Password account
group Manage the groups in your 1Password account
item Perform CRUD operations on the 1Password items in your vaults
plugin Manage the shell plugins you use to authenticate third-party CLIs
service-account Manage service accounts
user Manage users within this 1Password account
vault Manage permissions and perform CRUD operations on your 1Password vaults
Commands:
completion Generate shell completion information
inject Inject secrets into a config file
read Read a secret reference
run Pass secrets as environment variables to a process
signin Sign in to a 1Password account
signout Sign out of a 1Password account
update Check for and download updates.
whoami Get information about a signed-in account
Global Flags:
--account account Select the account to execute the command by account shorthand, sign-in address, account ID, or user ID. For a list
of available accounts, run 'op account list'. Can be set as the OP_ACCOUNT environment variable.
--cache Store and use cached information. Caching is enabled by default on UNIX-like systems. Caching is not available on
Windows. Options: true, false. Can also be set with the OP_CACHE environment variable. (default true)
--config directory Use this configuration directory.
--debug Enable debug mode. Can also be enabled by setting the OP_DEBUG environment variable to true.
--encoding type Use this character encoding type. Default: UTF-8. Supported: SHIFT_JIS, gbk.
--format string Use this output format. Can be 'human-readable' or 'json'. Can be set as the OP_FORMAT environment variable.
(default "human-readable")
-h, --help Get help for op.
--iso-timestamps Format timestamps according to ISO 8601 / RFC 3339. Can be set as the OP_ISO_TIMESTAMPS environment variable.
--no-color Print output without color.
--session token Authenticate with this session token. 1Password CLI outputs session tokens for successful 'op signin' commands when
1Password app integration is not enabled.
-v, --version version for op
Run 'op [command] --help' for more information on the command. into
send_for_platform, which has no such variable. Two existing unfurl tests caught
it — NameError at adapter.py:1407.
504 passed.
andrexibiza
reviewed
Sep 7, 2026
andrexibiza
left a comment
andrexibiza
left a comment
Contributor
There was a problem hiding this comment.
Reviewed exact head 93750e351a200d920b7abbd3c31858b8d2d4bd5f against current main 693641aa8b4359c602283bdbbc14041e03bc47bc, the 17-commit / 14-file surviving diff, the current exact-head CI/Docker/Nix receipts, the prior review and subsequent repair history, the new latch-specific tests, and the live overlapping FILE-LIST around Relay/Slack/send routing.
There is real progress here. The prior head's two most important security-contract defects are materially repaired: structured connector declines now survive through SendResult.raw_response instead of being reconstructed from prose, and route/guard uncertainty is treated fail-closed rather than silently granting permission. The newest commit also found two meaningful choke-point holes on its own: send_for_platform() was a direct egress door that bypassed the latch, and cosmetic success could incorrectly reopen content delivery. Those are good fixes, and exact-head CI/Docker/Nix are all green now.
Two landing blockers remain in the structural latch itself.
1. BLOCKER — the "turn" latch is actually adapter-lifetime state, and its advertised self-heal path cannot happen in production
_declined_chats lives on the long-lived RelayAdapter. There is no turn/session/generation identity in that state and no turn-boundary reset. Once a content op is refused, _outbound, _gated_op, and send_for_platform all short-circuit before asking the connector again. That means the connector cannot later accept a content op for that chat and trigger _clear_declined; the state can survive into later logical turns until adapter replacement or an internal/manual clear.
The current test named test_the_latch_clears_when_the_connector_accepts_again does not exercise connector acceptance at all — it calls adapter._clear_declined("C1") directly. So the test proves the private escape hatch, not the stated production contract.
This is the same authority-projection class the PR is trying to eliminate, just on the other axis: a decision scoped to one refused turn is projected into adapter-global chat state and later turns inherit it without new evidence. Required shape: bind the refusal latch to an actual turn/generation identity, or introduce an explicit safe reauthorization/reset lifecycle that cannot reopen same-turn fallback leakage. Please prove it with two real logical turns on the same adapter: turn A gets a connector decline and all same-turn alternate content ops stay off the wire; turn B, after the policy/destination becomes acceptable, succeeds without calling _clear_declined directly.
2. BLOCKER — _latch_key() is not a canonical destination identity
The new key is str(chat_id).split(":", 1)[0]. This PR's own gateway/relay/egress.py::_session_ids() now contains the correct opposite rule: recover parent/thread identity from structured fields, never by splitting, because Matrix room IDs such as !room:server.org contain native colons. The latch reintroduces that exact ambiguity and can collapse distinct rooms sharing the same prefix.
It also drops the underlying platform entirely even though one RelayAdapter explicitly fronts multiple platforms on one WebSocket. A Slack/Discord/Matrix destination collision on the same textual chat id therefore shares one refusal latch even though connector authorization is scoped to the actual (platform, destination).
The key needs to be a canonical structured destination identity: at minimum underlying platform + exact parent chat identity, with parent/thread inheritance derived from real thread metadata rather than delimiter parsing. Please add two negative controls: (a) two fronted platforms with the same textual chat_id, where a refusal on A must not mute B; and (b) Matrix-style room ids with native colons. Keep a positive parent→thread case, but drive it through the structured thread contract rather than a synthetic "C1:99" parser convention.
Verification proof gap
test_latch_covers_the_edit_to_send_lanes_without_a_local_check is parametrized over tool_progress, progress_overflow, heartbeat, and stale_final_reconcile, but the parameter never selects or executes those callers; every row only invokes adapter.edit_message() followed by adapter.send(). That is useful choke-point unit coverage, but it is not evidence that all four named production lanes actually traverse the choke point. This branch has already demonstrated why that distinction matters: send_for_platform() looked like another send lane until the latest commit proved it bypassed the common door. Please either execute the real four callers or rename the test so it does not claim caller-level coverage, then keep at least one real caller-level regression for each distinct direct egress door.
Interlock / landing topology
This is complementary, not duplicate, work relative to the current send/routing owners, but the FILE-LIST is not isolated:
- #73433 also changes
tools/send_message_tool.pyaround Slack DM target resolution. P5's guard must remain after resolution so it authorizes the exact destination actually sent. - #98445 also changes
gateway/run.pyaround interim/final send semantics. - #100022 changes both
gateway/run.pyandgateway/relay/adapter.pyto preserve strict Slack parent/thread affinity through Relay. That work and this latch must converge on one structured thread identity; delimiter-derived parenthood here must not overwrite its routing boundary.
The PR thread also records an explicit cross-repo merge prerequisite for Telegram @username: connector gateway-gateway#254 must land first so handles canonicalize to numeric ids before tenant routing. I could not independently resolve that connector PR through the available repository access, so I am preserving the dependency exactly as documented here rather than treating it as independently verified. Do not land the handle carve-out ahead of its declared prerequisite.
Current topology is clean against main: merge base is current main, 17 ahead / 0 behind. Exact-head CI, Docker, and Nix are all green on 93750e351a200d920b7abbd3c31858b8d2d4bd5f. That is a valid current-head receipt; it does not by itself substitute for the repository's every-surviving-commit acceptance rule.
The underlying direction is much stronger than the first reviewed head: typed refusal settlement now survives more of the graph, the author has been actively attacking the bypass surface instead of patching only named callers, and several earlier blockers are genuinely closed. Fix the latch's lifetime and identity rather than adding another local exception, reconcile the overlapping routing owners, and this becomes the structural boundary it is aiming to be. 🚀
| # inbound came from. Empty for a single-platform gateway (connector default). | ||
| self._platform_by_chat: Dict[str, str] = {} | ||
| # Chats the connector has refused (see the terminal-decline latch). | ||
| self._declined_chats: set[str] = set() |
Contributor
There was a problem hiding this comment.
This is described as a terminal decline "earlier in this turn", but the storage is adapter-lifetime and carries no turn/generation identity. Once this set contains the chat, every content door now short-circuits before the connector can accept a later attempt, so there is no production path for the advertised self-heal on a subsequent logical turn. Please scope this state to a real turn/generation (or add an explicit safe turn-boundary reauthorization/reset) and prove two successive turns on the same adapter without calling the private clear helper.
| also stop `chat:thread` frames — otherwise the same content reaches the | ||
| same conversation one level down. | ||
| """ | ||
| return str(chat_id).split(":", 1)[0].strip() |
Contributor
There was a problem hiding this comment.
This delimiter split is not a safe parent-chat derivation. The same PR already fixed this exact class in _session_ids() because Matrix room ids can contain native : (for example !room:server.org); splitting here collapses unrelated destinations. The latch also omits the underlying platform even though this adapter fronts multiple platforms. Please key by structured (platform, parent_chat) identity and derive thread parenthood from the actual thread metadata/contract, not from the textual chat id.
|
|
||
| asyncio.run(adapter.edit_message("C1", "m1", "x")) | ||
| asyncio.run(adapter.send("C1", "blocked")) | ||
| adapter._clear_declined("C1") |
Contributor
There was a problem hiding this comment.
This manual private clear means the test does not demonstrate the docstring's claim that the latch clears "when the connector accepts again". A latched content op never reaches the connector, so acceptance cannot trigger _clear_declined on the current production path. Replace this with a real second logical turn / reauthorization path and assert recovery without calling _clear_declined directly.
Round 8 blockers. Two of its four were already closed by 93750e3 (it reviewed the commit before it); these two are real and both are mine. B1 — THE TELEGRAM @handle EXEMPTION COVERED A NATIVE SEND. _is_unresolved_handle exempts telegram @Handles from attestation because "the connector resolves and authorizes it". That justification is FALSE whenever the gateway holds its own token: _send_to_platform calls _send_telegram(pconfig.token, ...) directly and no connector is involved. So an unattested @handle went out under the gateway's own credential while the numeric control was correctly refused. The exemption now requires that no native credential exists. A probe fault WITHDRAWS the exemption (falls back to the ordinary attestation check) rather than granting it. Shipped with the converse control: relay-only config still exempts @Handles, and numeric targets stay guarded in both modes. B4 — THE LATCH HAD NO BOUNDARY, SO IT WAS AN OUTAGE MECHANISM. My own regression, and worse than reported. Removing "clear on cosmetic success" (correctly) removed the ONLY way the latch could ever clear: a content op can never reach the connector to succeed, because the latch blocks it locally first. A refusal at 09:00 muted that chat forever. A new inbound message for a chat is the generation marker — the natural teardown point. Suppression still holds for the whole turn. same_turn_blocked: true next_turn_delivered: true MUTATIONS (all killed) handle exemption ignores native credential native-credential fault GRANTS the exemption no turn boundary (latch never clears) teardown clears ALL chats not just this one teardown ignores the chat The last two SURVIVED first: I tested _clear_declined_for_turn directly and never proved _on_inbound calls it — the caller-level gap that has now produced four blockers on this branch. Added a test driving the real inbound entry point. One self-inflicted bug, caught by my own fault test: the probe imported load_config, which does not exist (it is load_gateway_config), so it always threw and returned the fault default. The test that pinned fault behaviour is what exposed it. 510 passed.
Round 9, four blockers, all reproduced.
B1+B4 — THE TEARDOWN WAS AT THE WRONG PLACE, twice over.
It sat on the adapter's raw _on_inbound, which runs BEFORE profile
routing, the ignored-channel guard, plugin hooks and user authorization.
An unauthorized or dropped event could therefore clear a refusal
belonging to an active turn, and stale content then went out as a
different op. The same placement missed Discord interaction passthrough,
which builds its own MessageEvent and calls handle_message directly, so
slash commands and modal submits stayed muted after an earlier decline.
Both are one mistake: I picked a lane instead of a boundary. Teardown now
runs immediately after _hm_admit_event, the single admission gate every
entry path shares.
dropped event -> latch survives, stale send blocked
admitted event -> latch clears
B2 — THE LATCH KEY SPLIT ON ':', WHICH IS A MISTAKE I ALREADY FIXED ONCE.
_latch_key did str(chat_id).split(":", 1)[0], so !room:tenant-a and
!room:tenant-b both keyed !room: a decline in one Matrix room muted
another, and inbound from one cleared the other's refusal. egress.py
::_session_ids stopped doing exactly this in round 4 and I reintroduced
it three rounds later.
Parent identity is never recoverable from identifier TEXT. Thread
coverage is now structural: _thread_parent looks the relationship up in
the recorded auto-thread map.
B3 — AUTHORIZATION AND DISPATCH USED DIFFERENT CONFIG SNAPSHOTS.
_handle_send retains one pconfig; the guard independently reloaded
config. Across a transition the authorization snapshot could see a
connector-only setup (exemption granted) while dispatch still held the
native token and sent the unattested @handle itself. The guard now takes
native_token from the SAME snapshot dispatch will use. A caller that
omits it does not silently look like "no token".
NB-1/2/3 also closed: real-object snapshot tests, an exception shield
that faces a real exception, and send_follow_up no longer discards the
connector's verdict (that discard is exactly how the edit lane laundered
declines).
MUTATIONS (all killed)
latch key splits on colon again
thread parent lookup disabled
dispatch token ignored by guard
tool drops the snapshot token
admission teardown removed
teardown moved BEFORE admission
exception shield removed
follow_up drops raw_response
"admission teardown removed" SURVIVED first: I had tested the helper, not
_handle_message. Added a test driving production _handle_message with
admission stubbed both ways. Fifth caller-level gap on this branch.
One self-inflicted bug caught before commit: I passed pconfig.token in
_handle_react, which has no pconfig — a NameError on every reaction.
516 passed.
_thread_parent only sees connector auto-threads, and that map is capped at 256 entries, so a user-created or evicted thread does not inherit its parent's latch. Documented at the site and asserted by a test, because the alternative - deriving parents from identifier text - is exactly what muted unrelated Matrix rooms in round 9. The primary control is unaffected: authorize_relay_target takes thread_id as part of the destination and attests it on every send (6 thread tests).
…lanes
The extraction found a DEFECT, not just repetition.
Eight gateway lanes each hand-rolled the unwrapping of a decline from a
SendResult, and they did not agree. Six checked only raw_response. Two
also checked the error text. A connector that answers with the uniform
decline SENTENCE and no structured code - the documented contract for
older connectors, per _approval_send_outcome - was therefore classified
as an ordinary failure by those six lanes, so each treated a refusal as
"editing unavailable" and retried through another op.
Measured:
text-only decline six-site check False two-site check True
structured decline six-site check True two-site check True
No content leaked, because the adapter latch classifies the transport
dict directly and catches both shapes (verified: text-only decline still
latches C1 and keeps SECRET off the wire). The cost was wrong verdicts
and futile retries, not disclosure.
declined_send(result) in gateway/relay/egress.py now owns this. It checks
raw_response when structured, else the error text, and preserves the
ambiguous exclusion - an ambiguous result is a transport outcome, so it
must never read as a refusal.
run.py keeps its own shape deliberately: that lane has three verdicts
(ambiguous / declined / failed), so it checks ambiguous first and then
delegates the boolean.
MUTATIONS (all killed)
helper drops the text-only branch
helper drops the structured branch
ambiguous no longer excluded
draft lane decline check removed
edit-failure lane decline check removed
prompt verdict lane check removed
slash-confirm lane check removed
draft lane goes terminal on ANY failure (over-refusal direction)
"draft lane decline check removed" SURVIVED first: _send_draft_frame had
no test driving an unsuccessful send_draft at all. Added one, with an
ordinary-failure control so the fix cannot silently become "one flaky
frame mutes the chat". A non-unique anchor also masked the edit-failure
lane on the first pass - the trap my own skill warns about.
This closes the duplication that caused four of nine rounds of blockers:
a new lane now calls one classifier instead of copying three lines.
519 passed.
Round 10, four blockers, each reproduced before fixing. Two are my own
regressions from the previous two rounds.
B1 - ADMISSION IS NOT A NEW-TURN BOUNDARY.
Round 9 moved teardown to just after _hm_admit_event. That is only an
ADMISSION gate: an authorized message can be steered into a running
session, answer a pending prompt, run a busy slash command, or be refused
by the pause/drain gates - all without starting a turn. Each of those
cleared the ACTIVE turn's refusal, and a later fallback from that turn
reached the wire (probe: latch emptied, wire ops ['edit', 'send']).
Teardown now runs after _claim_active_session_slot, the first point the
runner OWNS a new turn. The new test drives production _handle_message
through all four non-turn lanes plus the real new-turn path.
B2 - LATCH IDENTITY OMITTED THE LOGICAL PLATFORM.
One relay adapter fronts several platforms, so native ids collide. A
Discord refusal for chat 42 was cleared by clear_egress_latch("telegram",
"42") - the method took a platform and ignored it - and the Discord
fallback then reached the connector. Keyed by normalized platform plus
exact chat id; thread-parent expansion keeps the platform component.
B3 - THE DIRECT DRAFT-SEAL PATH DID NOT ARM THE LATCH.
_seal_open_draft posts through _attempt directly rather than _outbound,
so a definite decline logged and returned but never latched. The
immediate plain-send fallback was suppressed by the caller's own check;
later same-turn sends were not (wire ['draft', 'draft', 'send'], the
third frame carrying refused content).
B4 - MY OWN REFACTOR MADE AMBIGUOUS RESULTS TERMINAL.
send_draft's ambiguous projection discarded raw_response, so
declined_send fell through to the error-text branch - and an ambiguous
result whose text carries the decline marker ("... egress declined: ack
lost") read as a DEFINITE refusal and terminated the run. Ambiguous means
the frame may well have been delivered: a transport outcome, never an
authorization one.
Fixed on both layers: the projection carries the body (and the seal's
ambiguous return is now explicit too), and declined_send's text-only
branch - which cannot see the ambiguous flag - treats ack-lost text as
transport ambiguity. Audited every SendResult projection in adapter.py
for the same shape.
MUTATIONS (all killed)
latch key drops the platform
clear_egress_latch ignores platform
draft seal does not arm the latch
ambiguous projection drops raw body
declined_send infers decline from ack-lost text
teardown back at admission
523 passed.
The latch moves to feat/p5-egress-decline-latch (pushed at 3cf4573, which retains the full history) for redesign. This PR keeps the authorization guard and the per-site decline checks. WHY. Across eleven review rounds the two halves behaved very differently. The guard is a PURE FUNCTION of the destination - its blockers were all "you asked the wrong question" (case sensitivity, nested ImportError, missing thread_id, config snapshot skew), each a one-line correction that then stayed fixed. Rounds 7-10 found nothing new in it. The latch is MUTABLE STATE WITH A LIFETIME living on RelayAdapter - an object registered once per process that holds the WebSocket and has no concept of a turn. Nine of its blockers reduce to three questions the adapter cannot answer: when does it end, who arms it, what is it keyed on. Every answer so far has been a proxy (a successful op, an inbound message, an admitted event, a claimed session slot) and every proxy was wrong in a lane found later. The per-site checks hold identical information on `st` - a PER-TURN object - and have produced zero blockers, because the state dies with the turn and nobody has to decide when it ends. The no-relaunder property does NOT depend on the latch. Measured on the real consumer path with the latch absent: a declined draft frame sets _egress_declined and puts nothing on the wire. Removal verified structurally rather than by eye: an AST diff of every symbol between HEAD and this tree reports only latch symbols gone, nothing added. That check caught two over-deletions my strip made - _on_inbound (consumed by a "next def" boundary) and _SEEN_INBOUND_MAX (a class constant inside the removed span). Both restored; 19 failures went to 0. ALSO: RESTORED A TEST I WRONGLY REPORTED AS PASSING. test_tool_guard_forwards_thread_id never made it into the repo - `git log -S` finds it in no commit - though round 5 recorded its mutant as killed. Dropping thread_id from the guard call therefore survived the entire tests/tools suite (146 passed). Written properly this time, driving the real _handle_send far enough to reach the guard. It now KILLS that mutant. MUTATIONS on this tree guard fault authorizes instead of refusing KILLED thread_id dropped from the guard call KILLED (was SURVIVED) handle exemption ignores native credential KILLED draft lane decline check removed KILLED prompt verdict lane check removed KILLED slash-confirm lane check removed KILLED 503 passed.
The thread_id test that was reported as killing a round-5 mutant turned
out never to have been committed. That is a reason to distrust the other
claimed kills, so I re-ran every guard mutation against the COMMITTED
tree instead of trusting the earlier reports.
Result: 9 of 11 killed, and the two "SKIPPED" ones had non-unique
anchors hiding SIX separate sites. Mutating those individually found
three real survivors.
CASE NORMALISATION (round 3, finding 3) WAS HALF-COVERED.
test_relay_fronted_matching_is_case_insensitive varies the CONFIGURED
name but always requests lowercase "discord", so it pins _relay_fronted's
normalisation and nothing else. The REQUESTED name's `.lower()` was
covered by nothing at all. Probe with it removed:
relay_routed("Discord") -> False
authorize("Discord", unattested) -> AUTHORIZED
which is exactly the bypass round 3 reported, alive again and untested.
Two further sites were untested in the OVER-REFUSAL direction: the
attested store is keyed lowercase, so a mixed-case request missed its own
attested set and refused legitimate traffic. attested_relay_targets' own
normalisation was invisible to every existing test because they all
monkeypatch that function away; it is now asserted against the real
function with only its leaf sources stubbed.
Three tests added. All six case sites now die when mutated.
I also re-did the three fail-closed RelayRouteUnknown mutations properly.
The first pass swapped whole lines and produced IndentationErrors, so
"KILLED" there proved nothing but a syntax error. Neutralising each raise
at correct indentation: all three genuinely KILLED.
FINAL AUDIT ON THIS TREE — 17 mutations, zero survivors
guard: thread_id dropped at the call site
guard: react path unguarded
guard: handle exemption ignores native credential
guard: 3x fail-closed raise neutralised
guard: 6x case-normalisation site
classifier: ambiguous treated as a decline
classifier: text-only decline branch removed
lane: draft / stream-edit / prompt / slash-confirm checks removed
511 passed.
Review of 45835a2 raised one blocking issue and three non-blocking ones. All four are addressed; none was a production defect. BLOCKING — the stream-edit test failed on the double, not on a leak. test_declined_stream_edit_does_not_send_the_unseen_tail implemented only the GUARDED path in its consumer double. Removing either guard therefore raised AttributeError inside the fake before any send could be observed: guard 1 removed -> AttributeError: no attribute '_is_flood_error' guard 2 removed -> AttributeError: no attribute '_clean_for_display' Red, but for the wrong reason — the test could not have caught the leak it is named for. My own docstring claimed it drove the fallback and checked the wire; it did neither. The double now implements everything the UNGUARDED path reaches (_is_flood_error, _flood_strikes, _current_edit_interval, _last_edit_time, _notify_new_message, _try_strip_cursor, _clean_for_display, _fallback_prefix, _metadata_for_send). Both mutations now fail on real assertions: guard 1 removed -> assert consumer._egress_declined is True guard 2 removed -> AssertionError: the unseen tail reached the wire: ['send'] NON-BLOCKING 1 — a docstring claimed more than the test exercises. test_requested_platform_name_is_also_normalised described a mixed-case send_message(target="Discord:999") bypass. That entry point cannot reach it: _resolve_tool_target lowercases the platform at tools/send_message_tool.py:47 before the guard runs. The test still pins a real contract — the helpers must not assume a lowercased argument, for the gateway lanes and any future non-normalising caller — so the claim is narrowed to that rather than the test removed. NON-BLOCKING 2 — the module docstring said "every lane drives the REAL RelayAdapter". The stream tests drive mixin doubles by design, because the behaviour under test belongs to the adapter's CALLER. Docstring now distinguishes the two kinds. NON-BLOCKING 3 — latch-deletion residue in gateway/relay/adapter.py:418: return None return latched if surface_declines else None The second line was unreachable and referenced a name deleted with the latch. Removed, along with the 20-line comment block describing the latch as "the structural fix" — that mechanism now lives on feat/p5-egress-decline-latch, not here. The reviewer independently confirmed the large deletion: an AST census between 3cf4573 and f57a229 reports only latch symbols removed and nothing added. 511 passed.
Review of 41ce3cc found no new production defect but three overstated claims, one of them in my own commit message. 1. THE LATCH COMMENTARY WAS STILL THERE. My previous commit message said it removed "the 20-line comment block describing the latch as the structural fix". It removed only the unreachable statement. Twenty lines at adapter.py:361-380 still described a per-chat latch, a choke point and its scope rules - none of which exist on this branch. In a refusal-sensitive module that reads as coverage this branch does not have. Now removed for real. This is the same defect class as the tests: a claim that outran what the code does. I made it while fixing that class. 2. THE STREAM-TEST DOCSTRING OVERSTATED BOTH MUTANTS. It said the mutation "now fails on the assertion that a send reached the wire" - true of one guard, not both. Verified separately: remove the _on_edit_failure check -> dies on _egress_declined, never reaches the fallback remove the fallback early return -> dies on the wire: ['send'] Both are valid behavioural failures, which is what the blocker asked for; they are different observables and the docstring now says so. 3. Duplicate `from types import SimpleNamespace` from an earlier scripted insert; imports reordered. 112 tests pass in the four focused files.
Both were reproduced before fixing and both mutants are pinned.
1. A LIVE relay adapter whose fronts_platform() raised degraded into the
config fallback. `_live_relay_fronted` returned None for every failure,
and None means "no live adapter, use the config snapshot" — so a faulting
adapter plus an empty/stale snapshot made the guard conclude "not
relay-routed" and authorize an unattested destination, while
resolve_delivery_transport asks that same adapter and still routes over
the relay. Measured: relay_routed=False, verdict None for chat 999.
Absence and fault now have separate return values: None only when there
is no runner or no relay adapter; a live adapter that cannot answer
raises RelayRouteUnknown. This is the third instance of this bug class in
this file, and the first two were also mine.
2. An attested chat whose id equalled the requested THREAD id vouched for
that thread. The `thread in attested` arm proved nothing about parentage.
Measured: attested {"-100A", "7"} authorized (-100A, thread 7).
Only the bound `parent:thread` form is accepted now. Nothing legitimate
needed the bare arm — _session_entry_id records a threaded origin as
f"{chat_id}:{thread_id}", and a thread addressed as its own channel
arrives as chat_id and passes the parent check.
The existing test blessed the bare form via parametrize, so it PINNED the
defect. Corrected, plus negative controls for the sibling-chat and
other-parent cases and a positive control proving genuine absence still
takes the config path (otherwise fix 1 would break native-only deploys).
Merged origin/main (was 22 behind). 428 passed via scripts/run_tests.sh;
full 10-row mutation ledger re-killed on the merged tree, none dying on an
exception rather than an assertion.
…ault Reviewer BLOCKER, reproduced before fixing. Two more paths where a PRESENT relay adapter still degraded into the config snapshot: 1. `fronts_platform` may be a property or descriptor, so the ATTRIBUTE LOOKUP can raise — and the lookup sat inside the absence handler. Probed with a raising property plus an empty snapshot: live=None, routed=False, verdict=None, i.e. an unattested target authorized. The previous test made an already-retrieved METHOD raise, so it could not reach this. 2. A present adapter with no usable `fronts_platform` returned None for the same reason. An adapter that cannot say what it fronts is broken, not absent, so it now raises too. Also found by my own spot-check while the review ran: the nested imports of `gateway.config` / `gateway.run` inside the live probe shared the broad handler, so a broken installation degraded to the snapshot as well. Probed with a healthy-adapter positive control in the same run — healthy refused the unattested target, faulted authorized it. `_relay_fronted` one function below already drew this exact distinction for its own import. The boundary is now: `relay is None` is the ONLY absence. Everything about a present adapter — attribute access, callability, the call itself, and the imports needed to reach it — is a fault and raises RelayRouteUnknown. This is the fourth variant of absence-vs-fault in this file and all four were mine. The lesson is in the code as a comment rather than in a commit message nobody re-reads. Four controls keep genuine absence benign: no runner, no relay adapter in the runner, a real ModuleNotFoundError naming the gateway package, and the configured-attested-target-still-sends case. 434 passed via scripts/run_tests.sh; 9-row mutation ledger re-killed including both new guards, none dying on an exception.
Reviewer BLOCKER round 2, reproduced: reading the adapter registry can also
raise. A runner whose `adapters.get()` raised gave relay_present=True,
live=None, routed=False, verdict=None — unattested discord:999 authorized.
That was the FIFTH boundary in one function with the same defect: the call,
the attribute lookup, a non-callable attribute, the nested imports, and now
the registry lookup. Each round I patched the reported boundary and the
defect moved one statement up. The cause was the shape, not the statements:
the function asked "did something go wrong?" and answered None, and None
MEANS "no live adapter, use the config snapshot" — so every statement was a
new chance to fail open, and every new statement would have been too.
Inverted rather than patched a sixth time. Each `return None` now sits
behind an explicit narrow check that cannot itself be the fault (no runner,
no adapters, no relay key, gateway package genuinely absent), and one outer
handler turns anything else into RelayRouteUnknown. A statement added inside
this function is now fail-CLOSED by default.
Verified all six fault shapes raise (call, attribute, missing method,
registry .get, .adapters property, runner ref) and all five absence shapes
stay benign, plus a liveness control where the config snapshot disagrees
with a healthy adapter and the adapter still wins.
Four new tests, including the two absence controls that keep native-only and
CLI deployments working. 438 passed via scripts/run_tests.sh. Mutation
ledger: 8 killed. One survivor recorded as a proven equivalent mutant —
widening `if not registry` to `or {}` is behaviourally identical because
`{}.get()` returns None, i.e. the same absence; it is a readability guard.
This was referenced Sep 8, 2026
mrkillbob
pushed a commit
to mrkillbob/hermes-agent
that referenced
this pull request
Sep 8, 2026
…s (P5) (NousResearch#99220) * fix(relay): authorize send_message targets and surface egress declines P5 of the relay egress-authorization workstream. The relay path authenticated the SENDER but never authorized the DESTINATION, and the gateway compounded it from both ends. (a) send_message could silently name an arbitrary relay target. Its `target` parameter is free-form ('platform:chat_id'), so a model could name ANY chat id and the gateway would emit an outbound frame for it. gateway/relay/egress.py adds an attestation floor: a relay-routed destination must have a provenance this gateway can show -- the operator's home channel, the channel directory, or its own gateway session origins. Anything else is refused HERE, with a visible tool error naming the target, before a frame is written. Non-relay platforms and platforms served by a live native adapter in this process are untouched (same precedence resolve_delivery_transport applies). (b) Connector declines were swallowed into apparent successes. The connector's egress floor answers an unauthorized destination with a DEFINITE failure whose text is deliberately uniform (F-005). Several relay lanes degrade a *transport drop* by design and were degrading an *authorization refusal* the same way: - _send_media returned None, sending the caller into BasePlatformAdapter's text fallback -- a DIFFERENT op re-addressed at the very chat the connector had just refused. - _send_prompt returned None, so exec-approval / slash-confirm / clarify reported "relay prompt op unavailable" (a wrong reason) and ran their numbered-text fallbacks into the refused chat. - task_card_stop discarded the error entirely. - typing / delete / react / thread ops degraded silently at debug. is_egress_decline() classifies THAT a decline happened (never why -- the uniform text is not parsed for reasons) and requires a definite, non-ambiguous failure, so a lost-ack retry is still a transport outcome. Lanes with an error-carrying contract now report the decline verbatim; cosmetic bool/None lanes still degrade but log it at WARNING. Advisory progress drops that legitimately degrade are unchanged: the task_card send lane, the draft ambiguous/except branches, and every transport-exception path keep their existing fail-open behaviour. Tests: 21 mutations of the production source, all KILLED. * fix(relay): authorize the RESOLVED target; declines must not fall back Review round 1 (independently confirmed by a second reviewer) found three blockers. Two are fixed here; the third (B-2, Telegram @username) is a policy decision left open deliberately. B-1 — THE FIX CAUSED THE OUTAGE IT PREVENTED (tools/send_message_tool.py) The P5(a) guard ran ABOVE Slack user->DM resolution, so it authorized the internal pseudo-id `_parse_target_ref` emits (`user_name:ben`, `user:U...`). Provenances only ever hold RESOLVED conversation ids, so a fully attested DM was compared as a handle against a set of `D...` ids and refused: base slack:@ben SENT head(before) slack:@ben REFUSED Every Slack DM by handle was broken. Moved the guard below resolution; it now authorizes the destination that is actually sent to, and the refusal names the resolved id. Position is load-bearing, so it is commented as such and pinned: reverting the move turns exactly the four new cases red. B-3 — A DECLINE IS NOT A LANE FAILURE (gateway/run.py) `_approval_send_outcome` had only sent/failed/ambiguous, so a connector decline collapsed into `failed` — which is the cue to run the plain-text fallback into the chat the connector had just refused. The adapter fix in the previous commit improved the error STRING while user-visible behaviour stayed identical to base; the commit message overstated it. Fixed properly: - new `declined` verdict, recognised via the shared `is_egress_decline` contract (not string sniffing at the call site) - exec-approval returns without the text fallback - slash-confirm suppresses the text reply AND clears the registration, so a card that never rendered cannot capture the user's next message `send_clarify` was already correct (returns early inside the adapter). MUTATIONS (production source; both directions) classifier never returns 'declined' -> KILLED (4 cases) ALL failures classified as 'declined' -> KILLED (2 cases) guard moved back above Slack resolution -> KILLED (4 cases) decline CODE changed (review M05) -> KILLED marker match made case-sensitive (M10) -> KILLED M05 was a tautology: the test asserted the imported constant against itself, so changing the constant could not fail it. The wire contract is now pinned as a literal, because the connector stamps that exact string and a one-sided change is a silent cross-repo break. REGRESSION CHECK: the 12 failures + 1 collection error in this test selection are PRE-EXISTING cross-test contamination — the identical set fails at 7cf86188ac. Verified by diffing the failing sets: no new failures, 363 -> 374 passed. NOT FIXED (deliberate): B-2, Telegram `@username`. The Bot API resolves handles at send time, so there is no id to compare and no canonicalization exists yet. That is a policy decision, not a code move. * fix(relay): fail CLOSED on guard faults; classify the structured decline Third independent review. Two more blockers, both reproduced before fixing. 1. THE GUARD ITSELF FAILED OPEN (tools/send_message_tool.py:158) `_authorize_relay_target` wrapped BOTH the import and the call in one `except Exception: return None` — and None means AUTHORIZED at every call site. So any runtime bug inside the guard silently switched the entire P5(a) boundary off. Reproduced: with the guard raising, an unattested target sent. The docstring already stated the correct intent ("must not fail closed on its own IMPORT error") and the code did something broader. The two failures are not the same: a missing gateway package means there is no relay egress to authorize; a fault inside the guard means authorization did not happen. The import is tolerated, the call is not — a guard that cannot answer refuses. 2. THE STRUCTURED DECLINE WAS THROWN AWAY (gateway/run.py) The adapter preserves the connector's dict in `SendResult.raw_response`. My previous commit rebuilt a dict from the error STRING, which loses two contracts: * a decline carrying `code: egress_declined` and NO text renders as "relay egress declined" — no marker colon — so it classified as `failed`, which is exactly the cue to run the fallback into the refused chat; * `ambiguous: True` (lost ack) was flattened into a DEFINITE failure, re-sending a card that may already be on the user's screen. That is the duplicate-card bug the ambiguous verdict exists to prevent, reintroduced by the fix meant to harden the same path. Both call sites now classify `raw_response` when present, ambiguity first, and fall back to the wire sentence only for connectors that send no structured response. I had fixed the text-marker path and tested only the text-marker path. Worth naming: the review's probe was a shape my tests never produced. MUTATIONS (production source) guard fault returns None (fail open again) -> KILLED classifier ignores raw_response -> KILLED (3 cases) ambiguous treated as a definite failure -> KILLED (2 cases) 40 focused tests pass. Regression check vs be321faf27: identical 13-item failing set (pre-existing cross-test contamination), no new failures. STILL OPEN: B-2 / finding 3, Telegram `@username`. The reviewer is right that this is a REGRESSION of an existing contract (#53573 added Bot API username support), not merely an unspecified input, since relay provenance stores the numeric chat id. Fixing it means resolving the handle before authorization, or explicitly revoking the contract. That is a policy decision, not a code move, and it is Ben's call. * test(relay): pin M21 and M25, the survivors whose comments called them load-bearing Round-2 review reported six unpinned survivors from round 1. Two guard real behaviour and are now covered; the other four are cosmetic-lane warnings and fail-open branches I am leaving documented rather than pretending to close. M25 — thread-qualified session ids. `_session_ids` adds BOTH "chat:thread" and the bare chat, because the connector authorizes the CHAT. Without the split a gateway whose session origin is `-100999:77` cannot send to `-100999`, the chat it is demonstrably already talking in. KILLED. M21 — the generic `relay` plane must union every fronted platform, since a relay session is filed under its LOGICAL platform. KILLED. MY FIRST M21 TEST WAS THE DEFECT IT WAS TESTING FOR. I patched `_relay_fronted` — the very function the mutation empties — so emptying it changed nothing the test could see, and the mutation SURVIVED against a green test. Rewritten to drive the real `relay_fronted_platforms()` through its env source (`GATEWAY_RELAY_PLATFORMS`), which is how production learns it. That is the same "the test verifies my stand-in" failure I have spent this workstream removing from the connector harnesses, reproduced here in three lines of Python. The tell was identical: a mutation that survives a test written specifically to kill it. 334 tests pass. NOT PINNED, deliberately: M03 (success-guard on a malformed dict), M24 (empty-target allowance — the one fail-open branch, reachable only when the bare-platform path already resolved a home channel), M35/M36 (decline WARNINGs on cosmetic lanes). All four are observability or defence-in-depth rather than authorization, and the review agrees they are non-blocking. * fix(relay): defer Telegram @username authorization to the connector (B-2) Closes the last blocker. Two reviewers independently called this a REGRESSION of the public-channel username support added in #53573, not an unspecified input, and they were right: provenance stores RESOLVED numeric chat ids, so comparing `@channel` against them could only ever refuse. WHY THE GATEWAY CANNOT ANSWER IT. The guard fires only when there is no live native adapter — i.e. relay-fronted deployments — and on exactly those the CONNECTOR holds the bot token, not this process. There is no local way to turn a handle into the numeric id. Refusing here is not "fail closed", it is "fail always". WHY DEFERRING IS SAFE. The destination is still authorized one layer out: the connector's Telegram egress floor (gg#238, merged 743a7c2) classifies and refuses unauthorized destinations after ITS resolution — the layer that closed the reported vulnerability in the first place. Handles go from two guards to one, the authoritative one, not to zero. The carve-out is deliberately narrow and its EDGES are pinned, because the failure mode of an exemption is silent widening: telegram `@handle` -> deferred (the regression case) telegram numeric id -> still guarded matrix `@user:server` -> still guarded (telegram-only) bare name, no `@` -> still guarded attested handle -> normal path, attestation still consulted MUTATIONS carve-out widened to all platforms -> KILLED carve-out widened to every target -> KILLED carve-out removed (regression back) -> KILLED carve-out checked BEFORE attestation -> KILLED THE ORDERING MUTANT SURVIVED MY FIRST TEST. Both orderings return None, so asserting the verdict could not tell them apart — the test asserted the claim instead of the mechanism. Rewritten to observe that attestation is actually consulted. Same defect class as the M21 test earlier in this branch: a mutation surviving a test written specifically to kill it means the test is measuring the wrong thing. 341 tests pass. FOLLOW-UP (option 2, Ben's call, deliberately NOT done here): resolve the handle before authorizing so BOTH layers apply. That needs a resolution round-trip through the connector — new wire surface — so it belongs in its own phase rather than bolted onto this one. Recorded in the code comment at the carve-out, not just here. * fix(relay): close two fail-open boundaries; test the code-only decline for real Both blockers from review, each REPRODUCED before fixing. 1. STRUCTURED DECLINE HAD NO GUARD. Deleting `raw_response=result` from both `_send_prompt` return branches left all 34 tests green — a surviving, non-equivalent security mutant. The `code` field is the documented PREFERRED signal precisely because a connector may send no prose, and a caller rebuilding `{"success": False, "error": ...}` cannot see it. Cause: every existing case declines with marker TEXT. The evidence for the code-only path was a hand-built SimpleNamespace in a different file — a stand-in for the adapter, so it verified my fixture instead of production. Fixed with a CodeOnlyDecliningConnector driving the real `send_exec_approval` -> `_send_prompt`, feeding the REAL SendResult to the REAL `_approval_send_outcome`, plus the same shape on the media lane. drop raw_response SURVIVED (34 passed) -> KILLED 2. TWO FAIL-OPEN BOUNDARIES, both "absence" and "fault" sharing a return. `_relay_fronted` swallowed EVERY exception and returned an empty set, which `relay_routed_platform` reads as "not relay-routed" — skipping the guard. Probe, with a positive control in the same run: positive_control_denied = True discovery_fault_denied = False <- unattested target AUTHORIZED `_authorize_relay_target` caught every exception during IMPORT as "no gateway package". A module that exists and fails to initialize is a fault, not an absence, and returning None there means authorized. Now: ImportError alone is absence; anything else raises RelayRouteUnknown and `authorize_relay_target` converts it to a REFUSAL STRING (not a raised exception — every caller treats the return value as the verdict, so raising would trade a fail-open for a crash). Kept the converse under test so "fail closed" does not silently become "refuse everything in CLI/cron", which is the outage the broad except existed to prevent. discovery fault -> empty set KILLED RelayRouteUnknown -> authorized KILLED import fault -> authorized KILLED 397 passed (was 392, +5 new cases), zero failures. * fix(relay): close all seven review-round-3 blockers Every finding reproduced before fixing; every fix mutation-checked after. CONTENT LEAKS (the decline was laundered into a different op, same chat) #1 A declined DRAFT SEAL replayed as a plain send. On stream-is-the-message platforms the turn-final becomes draft(final=True); `_seal_open_draft` dropped the structured body, so `_absorb_into_open_draft` read a REFUSAL as a lane failure and fell through. Probe, Slack descriptor: before: draft(partial) -> draft(final,SECRET) -> send(SECRET) after: draft(partial) -> draft(final,SECRET) My first probe of this used a discord descriptor and showed no seal at all — the leak is real, my probe was wrong (streams only arm for Slack). #6 Task-card PROGRESS had the same defect one lane over: a bare failed SendResult reads as "card lane unavailable", and TurnRunner then sends the task text to the same chat. Both card methods now carry raw_response and the caller suppresses the fallback on a decline. AUTHORIZATION BYPASSES #2 `except ImportError` was NOT the fix I claimed last round. ImportError also covers a broken dependency inside an INSTALLED gateway; review probed `ImportError.name = "gateway.relay.dependency"` and got an authorized verdict. Now only a name identifying the gateway relay module itself is absence. An ImportError with NO name stays absence — refusing on a fault we cannot attribute would trade an unidentifiable bug for a real CLI/cron outage, and an existing test caught exactly that when I first got it wrong. #3 `relay_routed_platform` lowercases the requested platform; `_relay_fronted` returned configured names verbatim. A platform configured as "Discord" missed the membership test, looked native, and skipped the guard: 'discord' => refused 'Discord' => ALLOWED 'DISCORD' => ALLOWED An attestation bypass on a string comparison. UNDELIVERABLE PROMPTS THAT HUNG #4 `_clarify_send_disposition` handled `failed` and `ambiguous` but not `declined`, so a REFUSED clarify card fell through to wait_for_response and blocked until clarify_timeout — indefinitely when configured non-positive. A decline is more definitive than a failure, not less. #5 The exec-approval decline branch returned quietly, which suppressed the text fallback (right) but left the CENTRAL approval entry pending (wrong) — the dangerous command stayed blocked until the approval timeout. My comment claimed the registration was torn down; only RelayAdapter's private map was. It now raises `_ExecApprovalDeclined`, which propagates to `_await_gateway_decision`'s existing notify-failure path (drops the entry, unblocks the tool). A dedicated type, re-raised past the local `except Exception` that would otherwise have restored the leak. #7 THE GAP THAT LET ALL OF THIS SHIP. Both caller-level suppressions were unfalsifiable: deleting either branch left 36/38 tests green. The suites drove `_approval_send_outcome` and `RelayAdapter` but never the real TurnRunner / busy-session callers, so nothing observed whether a text send FOLLOWED a decline — which is the whole property. tests/gateway/test_decline_fallback_suppression.py drives both real callers and records every send. Each decline case is paired with an ordinary-FAILURE control, because without one a caller that never falls back would also pass. MUTATIONS (all on production source, anchors count-checked, restored after) #1 seal decline -> plain send KILLED #1b seal drops raw_response KILLED #2 nested ImportError -> authorized KILLED #3 fronted set not normalized KILLED #4 clarify declined branch removed KILLED #5 approval decline returns not raises KILLED #6 task_card drops raw_response KILLED #7 slash-confirm suppression removed KILLED #7's two were the reviewer's SURVIVORS (36/38 passing); both now die. 425 passed, zero failures. * fix(relay): close the three round-4 blockers Round 4 confirmed six of seven round-3 fixes and found three more. Each reproduced before fixing, each mutation-checked after. 1. A NAMELESS ImportError still authorized. Last round I admitted it as "absence" to protect the CLI/cron path. That reasoning was WRONG and the interpreter says so: import gateway.relay.nope -> ModuleNotFoundError, name="gateway.relay.nope" import totally_absent_pkg -> ModuleNotFoundError, name="totally_absent_pkg" Genuine absence is ALWAYS ModuleNotFoundError with `.name` set, so the CLI/cron path never produces a bare ImportError and nothing legitimate was being protected. A plain or nameless ImportError comes from an import hook or a module that failed while initializing — an unattributable FAULT. Now: absence is ModuleNotFoundError naming gateway / gateway.relay / gateway.relay.egress; everything else refuses. Two existing tests raised a bare ImportError to simulate absence and were corrected to the real shape. 2. SESSION ATTESTATION INVENTED IDS. `_session_ids` split every id on the first colon to recover "chat" from "chat:thread". Matrix ids contain a colon natively, so `!room:server.org` attested a bare `!room` — the guard vouching for a destination on its own fabrication. The split now applies only to platforms whose ids genuinely carry a `:thread` suffix (allow-list; unknown platforms are treated as un-splittable, which can only refuse more). Kept a Slack control: dropping the split entirely would refuse legitimate thread replies, which is the outage the split exists to prevent. 3. THE TASK-CARD FIX WAS UNFALSIFIABLE — my own round-3 mistake, and the same one round 3 caught me making. I added the production branch AND a test, but the test stopped at RelayAdapter: it proved `raw_response` is carried and never called `TurnRunner._task_card_publish`, which owns the property. Deleting the real branch left 30 tests green. Now driven through the real caller, with an ordinary-failure control. The lesson generalises: proving the DATA reaches the boundary is not proving the CALLER acts on it. Every one of these decline fixes has two halves and the second half is where the security lives. Also closed the round-4 non-blocking finding: `gateway/relay/egress.py` has its OWN import boundary, and the existing test intercepted the earlier import in tools/send_message_tool.py, so it was never exercised. Mutating that classifier to treat every ImportError as absence now dies. MUTATIONS (production source, anchors count-checked, restored after) R4-1 nameless ImportError -> authorized KILLED R4-2 session split unconditional KILLED R4-3 task-card caller branch removed KILLED (was SURVIVED) egress classifier: any ImportError = absence KILLED Also probed and found NOT a leak: a refused OPENING draft frame disarms the stream and the turn-final goes out via `send`. That send is itself guarded and the connector refuses it too, so no content is delivered — unlike the seal case (round 3, #1) where the seal was the only check on that path. 452 passed, zero failures. * fix(relay): recover the thread parent from thread_id, not a colon split Round 4 blocker 2 was closed with an allow-list of platforms whose ids have no native colon. Reviewing my own fix while round 5 ran, the allow-list is the wrong mechanism: it NARROWS a guess instead of removing it, and it still gets Matrix wrong the moment a Matrix session is thread-qualified (`!room:server.org:$thr` -> split yields `!room`). The structured field was there all along. `_session_entry_id` composes the id as f"{chat_id}:{thread_id}" and the entry still carries `thread_id` separately, so the parent is knowable EXACTLY: strip the known suffix, or add nothing. No platform list, no guessing, correct for ids that contain colons. Mutations: back to splitting on the first colon KILLED thread parent never recovered (over-refuse) KILLED Both directions matter: the first invents attestations, the second refuses legitimate thread replies. One existing test (M25) asserted the right PROPERTY with a fixture that omitted `thread_id` — a shape real entries never have. Fixture corrected, assertions untouched. 453 passed. * fix(relay): close the four round-5 blockers Each reproduced before fixing, each mutation-checked after. R5-1 A DISABLED NATIVE ADAPTER BYPASSED AUTHORIZATION. `_has_live_native_adapter` treated any entry in the adapter map as native; `resolve_delivery_transport` ignores a native adapter whose config is disabled and routes over Relay. Two independent routing classifiers, disagreeing: guard says native: True delivery routes relay: True So the guard skipped authorization for a send that went over the relay. The guard now applies the router's enabled-state rule; probed both configurations and they agree. R5-2 THREAD IDS WERE NEVER AUTHORIZED. The parser splits chat_id and thread_id; only chat_id reached the guard. On Discord the thread IS the destination — `POST /channels/{thread_id}/messages` — so an attested parent channel authorized an arbitrary caller-supplied thread. `authorize_relay_target` now takes thread_id and requires its own attestation (bare id or the `chat:thread` form a session origin produces); both call sites forward it. R5-3 A DECLINED **INITIAL** DRAFT WAS RETRIED AS A PLAIN SEND. Round 3 fixed the declined SEAL; the declined OPEN was a different path. `send_draft` returned a bare failure, so the stream consumer read "draft transport unusable", disabled drafts and fell through to `_first_send`. Measured through the real adapter and real StreamTransportMixin: before: ops ['draft', 'send'] after: ops ['draft'] send_draft now carries raw_response; a decline is terminal for the run and the guard sits in `_first_send`, where every fallback path converges. R5-4 MY ROUND-4 TASK-CARD FIX SUPPRESSED EXACTLY ONE UPDATE. It set `native_failed`, which the entry gate already uses for an ordinary broken lane, so the next progress event skipped the decline branch and went straight to the text fallback: after first publish: [] after second: ['send'] Terminal declines are now a separate `egress_declined` state checked at the entry gate. A refusal does not expire after one tick. MUTATIONS R5-1 disabled native counts as native KILLED R5-2 thread_id not authorized KILLED R5-2b tool does not forward thread_id KILLED (was SURVIVED) R5-3 initial-draft decline not terminal KILLED R5-3b _first_send guard removed KILLED R5-4 declined state not persistent KILLED R5-2b is the same gap that produced findings 3 and 4 of the last two rounds, a third time: every test called `authorize_relay_target` directly, so dropping the argument from the TOOL WRAPPER changed nothing. Testing the callee never proves the caller uses it — now pinned explicitly. Each fix ships with an ordinary-failure control, because every one of these makes the guard refuse MORE, and over-refusal is now the larger risk. 474 passed, zero failures. * refactor(relay): declare the terminal-decline state where it lives Both terminal-decline flags were set dynamically. They worked (neither class is frozen or slotted) but an undeclared attribute hides the state from anyone reading the class, and this one is security-relevant. _TaskCardState.egress_declined — declared dataclass field StreamConsumer._egress_declined — initialised in __init__ Lifetime verified while checking whether a refusal can leak ACROSS turns and mute a healthy destination: it cannot. _TaskCardState is constructed per progress-drain (run_turn_runner.py:420) and the consumer's flags per run (stream_consumer.py:163), so both are fresh each turn. Also verified the guard's blast radius after adding thread authorization: the ONLY callers of authorize_relay_target are the two model-facing send_message call sites. Gateway-internal sends — notably the handoff path, which creates a thread and immediately posts to it with no session provenance yet — go through transport.adapter directly and are unaffected. That was the most plausible over-refusal, and it does not reach this guard. 461 passed. * fix(relay): close the four round-6 blockers — the edit lane R6-1 MY OWN R5-1 FIX REINTRODUCED THE BYPASS IT CLOSED. I wrote `except Exception: return True` around the config lookup, so a config read fault declared the platform native while the ROUTER, reading the real config, sends over the relay: guard_has_live_native True guard_verdict None router relay Routing we cannot determine is UNKNOWN. It now raises RelayRouteUnknown, which the outer handler must re-raise rather than flatten to False, and `authorize_relay_target` turns into a refusal. This is the second time a convenience `except` in this function created a bypass; there is now no permissive return left in it. R6-2/3/4 THE NINTH LANE: `edit`. ONE dropped field, THREE leaks. `RelayAdapter.edit_message` discarded the connector response, and three independent callers read a bare edit failure as "editing is unavailable" and re-send the content as a NEW message to the same chat: stream edit fallback ['edit', 'edit', 'send'] the unseen tail queued reconciliation ['edit', 'send'] the WHOLE response task-card fallback ['edit', 'send'] the task text again Fixed at the source (edit_message carries raw_response) plus each caller: `_on_edit_failure` — the single funnel for stream edit failures — makes a decline terminal for the run, `_send_fallback_final` refuses to deliver a continuation after one, the queued reconciler returns instead of sending, and the task-card fallback sets the same terminal state R5-4 introduced. R5-4 fixed the native task-card op and I did not check its sibling fallback path. The pattern across rounds 3-6 is consistent: the fix goes where the decline is OBSERVED, and the leak lives wherever someone else later decides to retry. MUTATIONS R6-1 config fault -> assume native KILLED R6-1b RelayRouteUnknown swallowed as False KILLED R6-2 edit drops raw_response KILLED R6-2b edit-failure decline not terminal KILLED R6-3 queued reconcile falls back on decline KILLED R6-4 task-card fallback edit decline KILLED Each with an ordinary-failure control: a genuinely un-editable message must still be delivered, and a broken card lane must still reach the user. 481 passed, zero failures. * fix(relay): add a terminal-decline latch at the adapter choke point THE STRUCTURAL FIX, not a twelfth local check. Rounds 3-6 of review found ONE defect in eleven lanes: the connector refuses an op, and some caller downstream reads that as 'this lane is unavailable' and retries the same content through a DIFFERENT op against the SAME chat. Media, prompt, draft-open, draft-seal, native task card, task-card fallback edit, slash-confirm, exec-approval, clarify, stream edit, queued reconciliation. Each was closed by adding a check at one more call site. That approach cannot converge: gateway/ has ~60 outbound call sites, every one of them a place a future change can reintroduce this, and four consecutive review rounds each found another. The reviewer's own count of lanes is the argument against the per-site design. Every relay frame from every one of those callers passes through _transport.send_outbound. One latch there covers them all: once the connector refuses a chat, this adapter stops emitting CONTENT frames for that chat. Proven to subsume the local checks: with the stream-edit per-site check DISABLED, the leak probe still reports blocked=true — the frame never reaches the wire. The local checks stay as defence in depth and for their better error messages, but they are no longer the only thing standing between a decline and a re-addressed send. Scope is deliberately narrow, and each limit is mutation-pinned: per CHAT - a refusal must not mute other conversations CONTENT ops - typing/delete carry nothing; latching them would leave a stuck typing indicator for no security gain self-healing - cleared when the connector accepts that chat again, so a transient policy change does not need a restart Mutations: latch never set KILLED latch never consulted KILLED latch is global, not per-chat KILLED latch never clears KILLED 485 passed. * fix(relay): one route source; the latch already covered round 7's lanes Round 7 reviewed 573e41e294 — one commit BEFORE the terminal-decline latch — and independently reached the same conclusion I had: 'The per-call-site approach is structurally wrong. Use one turn-scoped choke point.' That is the latch in 6dbc004594. Its four 'still broken' lanes (tool-progress edit, progress-overflow edit, long-running heartbeat edit, stale streamed-final reconciliation) all share the shape edit_message->declined->adapter.send(same chat, same content), and NONE has a local check. Probed all four against the latch: tool_progress ops ['edit'] blocked progress_overflow ops ['edit'] blocked heartbeat ops ['edit'] blocked stale_final ops ['edit'] blocked That is the argument for the choke point, measured: lanes nobody patched are safe anyway. Pinned by a parametrized test named for those four lanes. R7-1 IS A REAL BYPASS THE LATCH DOES NOT COVER, and it is fixed here. The guard rebuilt routing from GATEWAY_RELAY_PLATFORMS while resolve_delivery_transport asks the CONNECTED adapter (fronts_platform, from the handshake identity set). Different snapshots: with env discovery stale or momentarily empty, the guard said 'native' and the router sent over the relay, skipping authorization. before: guard_relay_routed False / delivery relay after: guard_relay_routed True / delivery relay / unattested target refused The guard now asks the live adapter first and falls back to config only when there is no runner (CLI/cron) — pinned in both directions. R7-5 (non-blocking, and a fair hit): my stream-fallback test asserted _egress_declined and never drove _send_fallback_final, so removing that early return SURVIVED. The test now calls the real fallback and asserts the wire is untouched; the mutation dies. Mutations: R7-1 guard ignores the live adapter KILLED (was SURVIVED) R7-5 fallback early return removed KILLED (was SURVIVED) latch not consulted KILLED 491 passed. * fix(relay): close three holes found by attacking my own latch Round 8's brief told the reviewer to attack the latch. I did the same in parallel and found three real holes in it before the review returned. 1. send_for_platform BYPASSED THE LATCH ENTIRELY. It builds and posts its frame directly rather than through _outbound — and it is the delivery resolver's OWN entry point, so it is the single most important caller. before: ops ['edit', 'send'] after: ops ['edit'] gateway/AGENTS.md states the rule I had just broken: 'Seal-interception exists at BOTH egress doors (send() and send_for_platform()); a new egress door needs the same two checks.' The latch is a third such check and I had wired it to one door. 2. A COSMETIC SUCCESS CLEARED THE LATCH. Clearing on ANY success meant a typing indicator — routinely allowed for a chat whose content is refused — re-opened the door for the very next send: ops ['edit', 'typing', 'send'] Only a CONTENT op the connector accepted may clear it now. 3. A THREAD INSIDE A REFUSED CHAT WAS NOT COVERED. A thread lives inside its parent, so the same content reached the same conversation one level down: ops ['edit', 'send'] The latch key now strips the thread suffix. Also normalised int/str chat ids (callers pass both; a type mismatch would silently unlatch). MUTATIONS send_for_platform not latched KILLED cosmetic success clears the latch KILLED thread suffix not stripped KILLED draft-seal retry not latched SURVIVED — EQUIVALENT, proven: is unreachable while latched (a declined edit before the seal produces ZERO seal frames, measured). Kept as defence in depth because it posts directly, and documented at the site rather than covered by a test that could not fail. One self-inflicted bug on the way: a blanket replace put 1Password CLI brings 1Password to your terminal. Turn on the 1Password app integration and sign in to get started. Run 'op signin --help' to learn more. For more help, read our documentation: https://www.1password.dev/cli 1Password CLI is built using open-source software. View our credits and licenses: https://downloads.1password.com/op/credits/stable/credits.html Usage: op [command] [flags] Management Commands: account Manage your locally configured 1Password accounts connect Manage Connect server instances and tokens in your 1Password account document Perform CRUD operations on Document items in your vaults events-api Manage Events API integrations in your 1Password account group Manage the groups in your 1Password account item Perform CRUD operations on the 1Password items in your vaults plugin Manage the shell plugins you use to authenticate third-party CLIs service-account Manage service accounts user Manage users within this 1Password account vault Manage permissions and perform CRUD operations on your 1Password vaults Commands: completion Generate shell completion information inject Inject secrets into a config file read Read a secret reference run Pass secrets as environment variables to a process signin Sign in to a 1Password account signout Sign out of a 1Password account update Check for and download updates. whoami Get information about a signed-in account Global Flags: --account account Select the account to execute the command by account shorthand, sign-in address, account ID, or user ID. For a list of available accounts, run 'op account list'. Can be set as the OP_ACCOUNT environment variable. --cache Store and use cached information. Caching is enabled by default on UNIX-like systems. Caching is not available on Windows. Options: true, false. Can also be set with the OP_CACHE environment variable. (default true) --config directory Use this configuration directory. --debug Enable debug mode. Can also be enabled by setting the OP_DEBUG environment variable to true. --encoding type Use this character encoding type. Default: UTF-8. Supported: SHIFT_JIS, gbk. --format string Use this output format. Can be 'human-readable' or 'json'. Can be set as the OP_FORMAT environment variable. (default "human-readable") -h, --help Get help for op. --iso-timestamps Format timestamps according to ISO 8601 / RFC 3339. Can be set as the OP_ISO_TIMESTAMPS environment variable. --no-color Print output without color. --session token Authenticate with this session token. 1Password CLI outputs session tokens for successful 'op signin' commands when 1Password app integration is not enabled. -v, --version version for op Run 'op [command] --help' for more information on the command. into send_for_platform, which has no such variable. Two existing unfurl tests caught it — NameError at adapter.py:1407. 504 passed. * fix(relay): Telegram handle exemption + a turn boundary for the latch Round 8 blockers. Two of its four were already closed by 93750e351a (it reviewed the commit before it); these two are real and both are mine. B1 — THE TELEGRAM @HANDLE EXEMPTION COVERED A NATIVE SEND. _is_unresolved_handle exempts telegram @handles from attestation because "the connector resolves and authorizes it". That justification is FALSE whenever the gateway holds its own token: _send_to_platform calls _send_telegram(pconfig.token, ...) directly and no connector is involved. So an unattested @handle went out under the gateway's own credential while the numeric control was correctly refused. The exemption now requires that no native credential exists. A probe fault WITHDRAWS the exemption (falls back to the ordinary attestation check) rather than granting it. Shipped with the converse control: relay-only config still exempts @handles, and numeric targets stay guarded in both modes. B4 — THE LATCH HAD NO BOUNDARY, SO IT WAS AN OUTAGE MECHANISM. My own regression, and worse than reported. Removing "clear on cosmetic success" (correctly) removed the ONLY way the latch could ever clear: a content op can never reach the connector to succeed, because the latch blocks it locally first. A refusal at 09:00 muted that chat forever. A new inbound message for a chat is the generation marker — the natural teardown point. Suppression still holds for the whole turn. same_turn_blocked: true next_turn_delivered: true MUTATIONS (all killed) handle exemption ignores native credential native-credential fault GRANTS the exemption no turn boundary (latch never clears) teardown clears ALL chats not just this one teardown ignores the chat The last two SURVIVED first: I tested _clear_declined_for_turn directly and never proved _on_inbound calls it — the caller-level gap that has now produced four blockers on this branch. Added a test driving the real inbound entry point. One self-inflicted bug, caught by my own fault test: the probe imported load_config, which does not exist (it is load_gateway_config), so it always threw and returned the fault default. The test that pinned fault behaviour is what exposed it. 510 passed. * fix(relay): correct latch identity and boundary; one config snapshot Round 9, four blockers, all reproduced. B1+B4 — THE TEARDOWN WAS AT THE WRONG PLACE, twice over. It sat on the adapter's raw _on_inbound, which runs BEFORE profile routing, the ignored-channel guard, plugin hooks and user authorization. An unauthorized or dropped event could therefore clear a refusal belonging to an active turn, and stale content then went out as a different op. The same placement missed Discord interaction passthrough, which builds its own MessageEvent and calls handle_message directly, so slash commands and modal submits stayed muted after an earlier decline. Both are one mistake: I picked a lane instead of a boundary. Teardown now runs immediately after _hm_admit_event, the single admission gate every entry path shares. dropped event -> latch survives, stale send blocked admitted event -> latch clears B2 — THE LATCH KEY SPLIT ON ':', WHICH IS A MISTAKE I ALREADY FIXED ONCE. _latch_key did str(chat_id).split(":", 1)[0], so !room:tenant-a and !room:tenant-b both keyed !room: a decline in one Matrix room muted another, and inbound from one cleared the other's refusal. egress.py ::_session_ids stopped doing exactly this in round 4 and I reintroduced it three rounds later. Parent identity is never recoverable from identifier TEXT. Thread coverage is now structural: _thread_parent looks the relationship up in the recorded auto-thread map. B3 — AUTHORIZATION AND DISPATCH USED DIFFERENT CONFIG SNAPSHOTS. _handle_send retains one pconfig; the guard independently reloaded config. Across a transition the authorization snapshot could see a connector-only setup (exemption granted) while dispatch still held the native token and sent the unattested @handle itself. The guard now takes native_token from the SAME snapshot dispatch will use. A caller that omits it does not silently look like "no token". NB-1/2/3 also closed: real-object snapshot tests, an exception shield that faces a real exception, and send_follow_up no longer discards the connector's verdict (that discard is exactly how the edit lane laundered declines). MUTATIONS (all killed) latch key splits on colon again thread parent lookup disabled dispatch token ignored by guard tool drops the snapshot token admission teardown removed teardown moved BEFORE admission exception shield removed follow_up drops raw_response "admission teardown removed" SURVIVED first: I had tested the helper, not _handle_message. Added a test driving production _handle_message with admission stubbed both ways. Fifth caller-level gap on this branch. One self-inflicted bug caught before commit: I passed pconfig.token in _handle_react, which has no pconfig — a NameError on every reaction. 516 passed. * docs(relay): pin the latch's thread coverage limit as a deliberate trade _thread_parent only sees connector auto-threads, and that map is capped at 256 entries, so a user-created or evicted thread does not inherit its parent's latch. Documented at the site and asserted by a test, because the alternative - deriving parents from identifier text - is exactly what muted unrelated Matrix rooms in round 9. The primary control is unaffected: authorize_relay_target takes thread_id as part of the destination and attests it on every send (6 thread tests). * refactor(relay): one SendResult decline classifier for all 8 gateway lanes The extraction found a DEFECT, not just repetition. Eight gateway lanes each hand-rolled the unwrapping of a decline from a SendResult, and they did not agree. Six checked only raw_response. Two also checked the error text. A connector that answers with the uniform decline SENTENCE and no structured code - the documented contract for older connectors, per _approval_send_outcome - was therefore classified as an ordinary failure by those six lanes, so each treated a refusal as "editing unavailable" and retried through another op. Measured: text-only decline six-site check False two-site check True structured decline six-site check True two-site check True No content leaked, because the adapter latch classifies the transport dict directly and catches both shapes (verified: text-only decline still latches C1 and keeps SECRET off the wire). The cost was wrong verdicts and futile retries, not disclosure. declined_send(result) in gateway/relay/egress.py now owns this. It checks raw_response when structured, else the error text, and preserves the ambiguous exclusion - an ambiguous result is a transport outcome, so it must never read as a refusal. run.py keeps its own shape deliberately: that lane has three verdicts (ambiguous / declined / failed), so it checks ambiguous first and then delegates the boolean. MUTATIONS (all killed) helper drops the text-only branch helper drops the structured branch ambiguous no longer excluded draft lane decline check removed edit-failure lane decline check removed prompt verdict lane check removed slash-confirm lane check removed draft lane goes terminal on ANY failure (over-refusal direction) "draft lane decline check removed" SURVIVED first: _send_draft_frame had no test driving an unsuccessful send_draft at all. Added one, with an ordinary-failure control so the fix cannot silently become "one flaky frame mutes the chat". A non-unique anchor also masked the edit-failure lane on the first pass - the trap my own skill warns about. This closes the duplication that caused four of nine rounds of blockers: a new lane now calls one classifier instead of copying three lines. 519 passed. * fix(relay): latch identity, new-turn boundary, seal arming, ambiguity Round 10, four blockers, each reproduced before fixing. Two are my own regressions from the previous two rounds. B1 - ADMISSION IS NOT A NEW-TURN BOUNDARY. Round 9 moved teardown to just after _hm_admit_event. That is only an ADMISSION gate: an authorized message can be steered into a running session, answer a pending prompt, run a busy slash command, or be refused by the pause/drain gates - all without starting a turn. Each of those cleared the ACTIVE turn's refusal, and a later fallback from that turn reached the wire (probe: latch emptied, wire ops ['edit', 'send']). Teardown now runs after _claim_active_session_slot, the first point the runner OWNS a new turn. The new test drives production _handle_message through all four non-turn lanes plus the real new-turn path. B2 - LATCH IDENTITY OMITTED THE LOGICAL PLATFORM. One relay adapter fronts several platforms, so native ids collide. A Discord refusal for chat 42 was cleared by clear_egress_latch("telegram", "42") - the method took a platform and ignored it - and the Discord fallback then reached the connector. Keyed by normalized platform plus exact chat id; thread-parent expansion keeps the platform component. B3 - THE DIRECT DRAFT-SEAL PATH DID NOT ARM THE LATCH. _seal_open_draft posts through _attempt directly rather than _outbound, so a definite decline logged and returned but never latched. The immediate plain-send fallback was suppressed by the caller's own check; later same-turn sends were not (wire ['draft', 'draft', 'send'], the third frame carrying refused content). B4 - MY OWN REFACTOR MADE AMBIGUOUS RESULTS TERMINAL. send_draft's ambiguous projection discarded raw_response, so declined_send fell through to the error-text branch - and an ambiguous result whose text carries the decline marker ("... egress declined: ack lost") read as a DEFINITE refusal and terminated the run. Ambiguous means the frame may well have been delivered: a transport outcome, never an authorization one. Fixed on both layers: the projection carries the body (and the seal's ambiguous return is now explicit too), and declined_send's text-only branch - which cannot see the ambiguous flag - treats ack-lost text as transport ambiguity. Audited every SendResult projection in adapter.py for the same shape. MUTATIONS (all killed) latch key drops the platform clear_egress_latch ignores platform draft seal does not arm the latch ambiguous projection drops raw body declined_send infers decline from ack-lost text teardown back at admission 523 passed. * refactor(relay): split the terminal-decline latch out of the guard PR The latch moves to feat/p5-egress-decline-latch (pushed at 3cf45736d7, which retains the full history) for redesign. This PR keeps the authorization guard and the per-site decline checks. WHY. Across eleven review rounds the two halves behaved very differently. The guard is a PURE FUNCTION of the destination - its blockers were all "you asked the wrong question" (case sensitivity, nested ImportError, missing thread_id, config snapshot skew), each a one-line correction that then stayed fixed. Rounds 7-10 found nothing new in it. The latch is MUTABLE STATE WITH A LIFETIME living on RelayAdapter - an object registered once per process that holds the WebSocket and has no concept of a turn. Nine of its blockers reduce to three questions the adapter cannot answer: when does it end, who arms it, what is it keyed on. Every answer so far has been a proxy (a successful op, an inbound message, an admitted event, a claimed session slot) and every proxy was wrong in a lane found later. The per-site checks hold identical information on `st` - a PER-TURN object - and have produced zero blockers, because the state dies with the turn and nobody has to decide when it ends. The no-relaunder property does NOT depend on the latch. Measured on the real consumer path with the latch absent: a declined draft frame sets _egress_declined and puts nothing on the wire. Removal verified structurally rather than by eye: an AST diff of every symbol between HEAD and this tree reports only latch symbols gone, nothing added. That check caught two over-deletions my strip made - _on_inbound (consumed by a "next def" boundary) and _SEEN_INBOUND_MAX (a class constant inside the removed span). Both restored; 19 failures went to 0. ALSO: RESTORED A TEST I WRONGLY REPORTED AS PASSING. test_tool_guard_forwards_thread_id never made it into the repo - `git log -S` finds it in no commit - though round 5 recorded its mutant as killed. Dropping thread_id from the guard call therefore survived the entire tests/tools suite (146 passed). Written properly this time, driving the real _handle_send far enough to reach the guard. It now KILLS that mutant. MUTATIONS on this tree guard fault authorizes instead of refusing KILLED thread_id dropped from the guard call KILLED (was SURVIVED) handle exemption ignores native credential KILLED draft lane decline check removed KILLED prompt verdict lane check removed KILLED slash-confirm lane check removed KILLED 503 passed. * test(relay): close the phantom-coverage gaps the guard audit found The thread_id test that was reported as killing a round-5 mutant turned out never to have been committed. That is a reason to distrust the other claimed kills, so I re-ran every guard mutation against the COMMITTED tree instead of trusting the earlier reports. Result: 9 of 11 killed, and the two "SKIPPED" ones had non-unique anchors hiding SIX separate sites. Mutating those individually found three real survivors. CASE NORMALISATION (round 3, finding 3) WAS HALF-COVERED. test_relay_fronted_matching_is_case_insensitive varies the CONFIGURED name but always requests lowercase "discord", so it pins _relay_fronted's normalisation and nothing else. The REQUESTED name's `.lower()` was covered by nothing at all. Probe with it removed: relay_routed("Discord") -> False authorize("Discord", unattested) -> AUTHORIZED which is exactly the bypass round 3 reported, alive again and untested. Two further sites were untested in the OVER-REFUSAL direction: the attested store is keyed lowercase, so a mixed-case request missed its own attested set and refused legitimate traffic. attested_relay_targets' own normalisation was invisible to every existing test because they all monkeypatch that function away; it is now asserted against the real function with only its leaf sources stubbed. Three tests added. All six case sites now die when mutated. I also re-did the three fail-closed RelayRouteUnknown mutations properly. The first pass swapped whole lines and produced IndentationErrors, so "KILLED" there proved nothing but a syntax error. Neutralising each raise at correct indentation: all three genuinely KILLED. FINAL AUDIT ON THIS TREE — 17 mutations, zero survivors guard: thread_id dropped at the call site guard: react path unguarded guard: handle exemption ignores native credential guard: 3x fail-closed raise neutralised guard: 6x case-normalisation site classifier: ambiguous treated as a decline classifier: text-only decline branch removed lane: draft / stream-edit / prompt / slash-confirm checks removed 511 passed. * test(relay): make the stream-edit test fail for the right reason Review of 45835a282d raised one blocking issue and three non-blocking ones. All four are addressed; none was a production defect. BLOCKING — the stream-edit test failed on the double, not on a leak. test_declined_stream_edit_does_not_send_the_unseen_tail implemented only the GUARDED path in its consumer double. Removing either guard therefore raised AttributeError inside the fake before any send could be observed: guard 1 removed -> AttributeError: no attribute '_is_flood_error' guard 2 removed -> AttributeError: no attribute '_clean_for_display' Red, but for the wrong reason — the test could not have caught the leak it is named for. My own docstring claimed it drove the fallback and checked the wire; it did neither. The double now implements everything the UNGUARDED path reaches (_is_flood_error, _flood_strikes, _current_edit_interval, _last_edit_time, _notify_new_message, _try_strip_cursor, _clean_for_display, _fallback_prefix, _metadata_for_send). Both mutations now fail on real assertions: guard 1 removed -> assert consumer._egress_declined is True guard 2 removed -> AssertionError: the unseen tail reached the wire: ['send'] NON-BLOCKING 1 — a docstring claimed more than the test exercises. test_requested_platform_name_is_also_normalised described a mixed-case send_message(target="Discord:999") bypass. That entry point cannot reach it: _resolve_tool_target lowercases the platform at tools/send_message_tool.py:47 before the guard runs. The test still pins a real contract — the helpers must not assume a lowercased argument, for the gateway lanes and any future non-normalising caller — so the claim is narrowed to that rather than the test removed. NON-BLOCKING 2 — the module docstring said "every lane drives the REAL RelayAdapter". The stream tests drive mixin doubles by design, because the behaviour under test belongs to the adapter's CALLER. Docstring now distinguishes the two kinds. NON-BLOCKING 3 — latch-deletion residue in gateway/relay/adapter.py:418: return None return latched if surface_declines else None The second line was unreachable and referenced a name deleted with the latch. Removed, along with the 20-line comment block describing the latch as "the structural fix" — that mechanism now lives on feat/p5-egress-decline-latch, not here. The reviewer independently confirmed the large deletion: an AST census between 3cf45736d7 and f57a2298fa reports only latch symbols removed and nothing added. 511 passed. * docs(relay): correct three claims that outran the code Review of 41ce3cc765 found no new production defect but three overstated claims, one of them in my own commit message. 1. THE LATCH COMMENTARY WAS STILL THERE. My previous commit message said it removed "the 20-line comment block describing the latch as the structural fix". It removed only the unreachable statement. Twenty lines at adapter.py:361-380 still described a per-chat latch, a choke point and its scope rules - none of which exist on this branch. In a refusal-sensitive module that reads as coverage this branch does not have. Now removed for real. This is the same defect class as the tests: a claim that outran what the code does. I made it while fixing that class. 2. THE STREAM-TEST DOCSTRING OVERSTATED BOTH MUTANTS. It said the mutation "now fails on the assertion that a send reached the wire" - true of one guard, not both. Verified separately: remove the _on_edit_failure check -> dies on _egress_declined, never reaches the fallback remove the fallback early return -> dies on the wire: ['send'] Both are valid behavioural failures, which is what the blocker asked for; they are different observables and the docstring now says so. 3. Duplicate `from types import SimpleNamespace` from an earlier scripted insert; imports reordered. 112 tests pass in the four focused files. * fix(relay): close two authorization defects found in review Both were reproduced before fixing and both mutants are pinned. 1. A LIVE relay adapter whose fronts_platform() raised degraded into the config fallback. `_live_relay_fronted` returned None for every failure, and None means "no live adapter, use the config snapshot" — so a faulting adapter plus an empty/stale snapshot made the guard conclude "not relay-routed" and authorize an unattested destination, while resolve_delivery_transport asks that same adapter and still routes over the relay. Measured: relay_routed=False, verdict None for chat 999. Absence and fault now have separate return values: None only when there is no runner or no relay adapter; a live adapter that cannot answer raises RelayRouteUnknown. This is the third instance of this bug class in this file, and the first two were also mine. 2. An attested chat whose id equalled the requested THREAD id vouched for that thread. The `thread in attested` arm proved nothing about parentage. Measured: attested {"-100A", "7"} authorized (-100A, thread 7). Only the bound `parent:thread` form is accepted now. Nothing legitimate needed the bare arm — _session_entry_id records a threaded origin as f"{chat_id}:{thread_id}", and a thread addressed as its own channel arrives as chat_id and passes the parent check. The existing test blessed the bare form via parametrize, so it PINNED the defect. Corrected, plus negative controls for the sibling-chat and other-parent cases and a positive control proving genuine absence still takes the config path (otherwise fix 1 would break native-only deploys). Merged origin/main (was 22 behind). 428 passed via scripts/run_tests.sh; full 10-row mutation ledger re-killed on the merged tree, none dying on an exception rather than an assertion. * fix(relay): only a missing adapter is absence; everything else is a fault Reviewer BLOCKER, reproduced before fixing. Two more paths where a PRESENT relay adapter still degraded into the config snapshot: 1. `fronts_platform` may be a property or descriptor, so the ATTRIBUTE LOOKUP can raise — and the lookup sat inside the absence handler. Probed with a raising property plus an empty snapshot: live=None, routed=False, verdict=None, i.e. an unattested target authorized. The previous test made an already-retrieved METHOD raise, so it could not reach this. 2. A present adapter with no usable `fronts_platform` returned None for the same reason. An adapter that cannot say what it fronts is broken, not absent, so it now raises too. Also found by my own spot-check while the review ran: the nested imports of `gateway.config` / `gateway.run` inside the live probe shared the broad handler, so a broken installation degraded to the snapshot as well. Probed with a healthy-adapter positive control in the same run — healthy refused the unattested target, faulted authorized it. `_relay_fronted` one function below already drew this exact distinction for its own import. The boundary is now: `relay is None` is the ONLY absence. Everything about a present adapter — attribute access, callability, the call itself, and the imports needed to reach it — is a fault and raises RelayRouteUnknown. This is the fourth variant of absence-vs-fault in this file and all four were mine. The lesson is in the code as a comment rather than in a commit message nobody re-reads. Four controls keep genuine absence benign: no runner, no relay adapter in the runner, a real ModuleNotFoundError naming the gateway package, and the configured-attested-target-still-sends case. 434 passed via scripts/run_tests.sh; 9-row mutation ledger re-killed including both new guards, none dying on an exception. * fix(relay): invert the live probe to fail closed by default Reviewer BLOCKER round 2, reproduced: reading the adapter registry can also raise. A runner whose `adapters.get()` raised gave relay_present=True, live=None, routed=False, verdict=None — unattested discord:999 authorized. That was the FIFTH boundary in one function with the same defect: the call, the attribute lookup, a non-callable attribute, the nested imports, and now the registry lookup. Each round I patched the reported boundary and the defect moved one statement up. The cause was the shape, not the statements: the function asked "did something go wrong?" and answered None, and None MEANS "no live adapter, use the config snapshot" — so every statement was a new chance to fail open, and every new statement would have been too. Inverted rather than patched a sixth time. Each `return None` now sits behind an explicit narrow check that cannot itself be the fault (no runner, no adapters, no relay key, gateway package genuinely absent), and one outer handler turns anything else into RelayRouteUnknown. A statement added inside this function is now fail-CLOSED by default. Verified all six fault shapes raise (call, attribute, missing method, registry .get, .adapters property, runner ref) and all five absence shapes stay benign, plus a liveness control where the config snapshot disagrees with a healthy adapter and the adapter still wins. Four new tests, including the two absence controls that keep native-only and CLI deployments working. 438 passed via scripts/run_tests.sh. Mutation ledger: 8 killed. One survivor recorded as a proven equivalent mutant — widening `if not registry` to `or {}` is behaviourally identical because `{}.get()` returns None, i.e. the same absence; it is a readability guard.
mrkillbob
added a commit
to mrkillbob/hermes-agent
that referenced
this pull request
Sep 8, 2026
* fix(relay): authorize send_message targets and surface egress declines (P5) (#99220)
* fix(relay): authorize send_message targets and surface egress declines
P5 of the relay egress-authorization workstream. The relay path
authenticated the SENDER but never authorized the DESTINATION, and the
gateway compounded it from both ends.
(a) send_message could silently name an arbitrary relay target. Its
`target` parameter is free-form ('platform:chat_id'), so a model could
name ANY chat id and the gateway would emit an outbound frame for it.
gateway/relay/egress.py adds an attestation floor: a relay-routed
destination must have a provenance this gateway can show -- the
operator's home channel, the channel directory, or its own gateway
session origins. Anything else is refused HERE, with a visible tool
error naming the target, before a frame is written. Non-relay platforms
and platforms served by a live native adapter in this process are
untouched (same precedence resolve_delivery_transport applies).
(b) Connector declines were swallowed into apparent successes. The
connector's egress floor answers an unauthorized destination with a
DEFINITE failure whose text is deliberately uniform (F-005). Several
relay lanes degrade a *transport drop* by design and were degrading an
*authorization refusal* the same way:
- _send_media returned None, sending the caller into
BasePlatformAdapter's text fallback -- a DIFFERENT op re-addressed at
the very chat the connector had just refused.
- _send_prompt returned None, so exec-approval / slash-confirm /
clarify reported "relay prompt op unavailable" (a wrong reason) and
ran their numbered-text fallbacks into the refused chat.
- task_card_stop discarded the error entirely.
- typing / delete / react / thread ops degraded silently at debug.
is_egress_decline() classifies THAT a decline happened (never why --
the uniform text is not parsed for reasons) and requires a definite,
non-ambiguous failure, so a lost-ack retry is still a transport
outcome. Lanes with an error-carrying contract now report the decline
verbatim; cosmetic bool/None lanes still degrade but log it at WARNING.
Advisory progress drops that legitimately degrade are unchanged: the
task_card send lane, the draft ambiguous/except branches, and every
transport-exception path keep their existing fail-open behaviour.
Tests: 21 mutations of the production source, all KILLED.
* fix(relay): authorize the RESOLVED target; declines must not fall back
Review round 1 (independently confirmed by a second reviewer) found three
blockers. Two are fixed here; the third (B-2, Telegram @username) is a policy
decision left open deliberately.
B-1 — THE FIX CAUSED THE OUTAGE IT PREVENTED (tools/send_message_tool.py)
The P5(a) guard ran ABOVE Slack user->DM resolution, so it authorized the
internal pseudo-id `_parse_target_ref` emits (`user_name:ben`, `user:U...`).
Provenances only ever hold RESOLVED conversation ids, so a fully attested DM
was compared as a handle against a set of `D...` ids and refused:
base slack:@ben SENT head(before) slack:@ben REFUSED
Every Slack DM by handle was broken. Moved the guard below resolution; it now
authorizes the destination that is actually sent to, and the refusal names the
resolved id. Position is load-bearing, so it is commented as such and pinned:
reverting the move turns exactly the four new cases red.
B-3 — A DECLINE IS NOT A LANE FAILURE (gateway/run.py)
`_approval_send_outcome` had only sent/failed/ambiguous, so a connector
decline collapsed into `failed` — which is the cue to run the plain-text
fallback into the chat the connector had just refused. The adapter fix in the
previous commit improved the error STRING while user-visible behaviour stayed
identical to base; the commit message overstated it. Fixed properly:
- new `declined` verdict, recognised via the shared `is_egress_decline`
contract (not string sniffing at the call site)
- exec-approval returns without the text fallback
- slash-confirm suppresses the text reply AND clears the registration, so a
card that never rendered cannot capture the user's next message
`send_clarify` was already correct (returns early inside the adapter).
MUTATIONS (production source; both directions)
classifier never returns 'declined' -> KILLED (4 cases)
ALL failures classified as 'declined' -> KILLED (2 cases)
guard moved back above Slack resolution -> KILLED (4 cases)
decline CODE changed (review M05) -> KILLED
marker match made case-sensitive (M10) -> KILLED
M05 was a tautology: the test asserted the imported constant against itself,
so changing the constant could not fail it. The wire contract is now pinned as
a literal, because the connector stamps that exact string and a one-sided
change is a silent cross-repo break.
REGRESSION CHECK: the 12 failures + 1 collection error in this test selection
are PRE-EXISTING cross-test contamination — the identical set fails at
7cf86188ac. Verified by diffing the failing sets: no new failures, 363 -> 374
passed.
NOT FIXED (deliberate): B-2, Telegram `@username`. The Bot API resolves handles
at send time, so there is no id to compare and no canonicalization exists yet.
That is a policy decision, not a code move.
* fix(relay): fail CLOSED on guard faults; classify the structured decline
Third independent review. Two more blockers, both reproduced before fixing.
1. THE GUARD ITSELF FAILED OPEN (tools/send_message_tool.py:158)
`_authorize_relay_target` wrapped BOTH the import and the call in one
`except Exception: return None` — and None means AUTHORIZED at every call site.
So any runtime bug inside the guard silently switched the entire P5(a) boundary
off. Reproduced: with the guard raising, an unattested target sent.
The docstring already stated the correct intent ("must not fail closed on its
own IMPORT error") and the code did something broader. The two failures are not
the same: a missing gateway package means there is no relay egress to
authorize; a fault inside the guard means authorization did not happen. The
import is tolerated, the call is not — a guard that cannot answer refuses.
2. THE STRUCTURED DECLINE WAS THROWN AWAY (gateway/run.py)
The adapter preserves the connector's dict in `SendResult.raw_response`. My
previous commit rebuilt a dict from the error STRING, which loses two
contracts:
* a decline carrying `code: egress_declined` and NO text renders as
"relay egress declined" — no marker colon — so it classified as `failed`,
which is exactly the cue to run the fallback into the refused chat;
* `ambiguous: True` (lost ack) was flattened into a DEFINITE failure,
re-sending a card that may already be on the user's screen. That is the
duplicate-card bug the ambiguous verdict exists to prevent, reintroduced
by the fix meant to harden the same path.
Both call sites now classify `raw_response` when present, ambiguity first, and
fall back to the wire sentence only for connectors that send no structured
response.
I had fixed the text-marker path and tested only the text-marker path. Worth
naming: the review's probe was a shape my tests never produced.
MUTATIONS (production source)
guard fault returns None (fail open again) -> KILLED
classifier ignores raw_response -> KILLED (3 cases)
ambiguous treated as a definite failure -> KILLED (2 cases)
40 focused tests pass. Regression check vs be321faf27: identical 13-item
failing set (pre-existing cross-test contamination), no new failures.
STILL OPEN: B-2 / finding 3, Telegram `@username`. The reviewer is right that
this is a REGRESSION of an existing contract (#53573 added Bot API username
support), not merely an unspecified input, since relay provenance stores the
numeric chat id. Fixing it means resolving the handle before authorization, or
explicitly revoking the contract. That is a policy decision, not a code move,
and it is Ben's call.
* test(relay): pin M21 and M25, the survivors whose comments called them load-bearing
Round-2 review reported six unpinned survivors from round 1. Two guard real
behaviour and are now covered; the other four are cosmetic-lane warnings and
fail-open branches I am leaving documented rather than pretending to close.
M25 — thread-qualified session ids. `_session_ids` adds BOTH "chat:thread" and
the bare chat, because the connector authorizes the CHAT. Without the split a
gateway whose session origin is `-100999:77` cannot send to `-100999`, the chat
it is demonstrably already talking in. KILLED.
M21 — the generic `relay` plane must union every fronted platform, since a
relay session is filed under its LOGICAL platform. KILLED.
MY FIRST M21 TEST WAS THE DEFECT IT WAS TESTING FOR. I patched `_relay_fronted`
— the very function the mutation empties — so emptying it changed nothing the
test could see, and the mutation SURVIVED against a green test. Rewritten to
drive the real `relay_fronted_platforms()` through its env source
(`GATEWAY_RELAY_PLATFORMS`), which is how production learns it.
That is the same "the test verifies my stand-in" failure I have spent this
workstream removing from the connector harnesses, reproduced here in three
lines of Python. The tell was identical: a mutation that survives a test
written specifically to kill it.
334 tests pass.
NOT PINNED, deliberately: M03 (success-guard on a malformed dict), M24
(empty-target allowance — the one fail-open branch, reachable only when the
bare-platform path already resolved a home channel), M35/M36 (decline WARNINGs
on cosmetic lanes). All four are observability or defence-in-depth rather than
authorization, and the review agrees they are non-blocking.
* fix(relay): defer Telegram @username authorization to the connector (B-2)
Closes the last blocker. Two reviewers independently called this a REGRESSION
of the public-channel username support added in #53573, not an unspecified
input, and they were right: provenance stores RESOLVED numeric chat ids, so
comparing `@channel` against them could only ever refuse.
WHY THE GATEWAY CANNOT ANSWER IT. The guard fires only when there is no live
native adapter — i.e. relay-fronted deployments — and on exactly those the
CONNECTOR holds the bot token, not this process. There is no local way to turn
a handle into the numeric id. Refusing here is not "fail closed", it is "fail
always".
WHY DEFERRING IS SAFE. The destination is still authorized one layer out: the
connector's Telegram egress floor (gg#238, merged 743a7c2) classifies and
refuses unauthorized destinations after ITS resolution — the layer that closed
the reported vulnerability in the first place. Handles go from two guards to
one, the authoritative one, not to zero.
The carve-out is deliberately narrow and its EDGES are pinned, because the
failure mode of an exemption is silent widening:
telegram `@handle` -> deferred (the regression case)
telegram numeric id -> still guarded
matrix `@user:server` -> still guarded (telegram-only)
bare name, no `@` -> still guarded
attested handle -> normal path, attestation still consulted
MUTATIONS
carve-out widened to all platforms -> KILLED
carve-out widened to every target -> KILLED
carve-out removed (regression back) -> KILLED
carve-out checked BEFORE attestation -> KILLED
THE ORDERING MUTANT SURVIVED MY FIRST TEST. Both orderings return None, so
asserting the verdict could not tell them apart — the test asserted the claim
instead of the mechanism. Rewritten to observe that attestation is actually
consulted. Same defect class as the M21 test earlier in this branch: a
mutation surviving a test written specifically to kill it means the test is
measuring the wrong thing.
341 tests pass.
FOLLOW-UP (option 2, Ben's call, deliberately NOT done here): resolve the
handle before authorizing so BOTH layers apply. That needs a resolution
round-trip through the connector — new wire surface — so it belongs in its own
phase rather than bolted onto this one. Recorded in the code comment at the
carve-out, not just here.
* fix(relay): close two fail-open boundaries; test the code-only decline for real
Both blockers from review, each REPRODUCED before fixing.
1. STRUCTURED DECLINE HAD NO GUARD. Deleting `raw_response=result` from both
`_send_prompt` return branches left all 34 tests green — a surviving,
non-equivalent security mutant. The `code` field is the documented
PREFERRED signal precisely because a connector may send no prose, and a
caller rebuilding `{"success": False, "error": ...}` cannot see it.
Cause: every existing case declines with marker TEXT. The evidence for the
code-only path was a hand-built SimpleNamespace in a different file — a
stand-in for the adapter, so it verified my fixture instead of production.
Fixed with a CodeOnlyDecliningConnector driving the real
`send_exec_approval` -> `_send_prompt`, feeding the REAL SendResult to the
REAL `_approval_send_outcome`, plus the same shape on the media lane.
drop raw_response SURVIVED (34 passed) -> KILLED
2. TWO FAIL-OPEN BOUNDARIES, both "absence" and "fault" sharing a return.
`_relay_fronted` swallowed EVERY exception and returned an empty set, which
`relay_routed_platform` reads as "not relay-routed" — skipping the guard.
Probe, with a positive control in the same run:
positive_control_denied = True
discovery_fault_denied = False <- unattested target AUTHORIZED
`_authorize_relay_target` caught every exception during IMPORT as "no
gateway package". A module that exists and fails to initialize is a fault,
not an absence, and returning None there means authorized.
Now: ImportError alone is absence; anything else raises RelayRouteUnknown
and `authorize_relay_target` converts it to a REFUSAL STRING (not a raised
exception — every caller treats the return value as the verdict, so raising
would trade a fail-open for a crash).
Kept the converse under test so "fail closed" does not silently become
"refuse everything in CLI/cron", which is the outage the broad except
existed to prevent.
discovery fault -> empty set KILLED
RelayRouteUnknown -> authorized KILLED
import fault -> authorized KILLED
397 passed (was 392, +5 new cases), zero failures.
* fix(relay): close all seven review-round-3 blockers
Every finding reproduced before fixing; every fix mutation-checked after.
CONTENT LEAKS (the decline was laundered into a different op, same chat)
#1 A declined DRAFT SEAL replayed as a plain send. On stream-is-the-message
platforms the turn-final becomes draft(final=True); `_seal_open_draft`
dropped the structured body, so `_absorb_into_open_draft` read a REFUSAL as
a lane failure and fell through. Probe, Slack descriptor:
before: draft(partial) -> draft(final,SECRET) -> send(SECRET)
after: draft(partial) -> draft(final,SECRET)
My first probe of this used a discord descriptor and showed no seal at all —
the leak is real, my probe was wrong (streams only arm for Slack).
#6 Task-card PROGRESS had the same defect one lane over: a bare failed
SendResult reads as "card lane unavailable", and TurnRunner then sends the
task text to the same chat. Both card methods now carry raw_response and
the caller suppresses the fallback on a decline.
AUTHORIZATION BYPASSES
#2 `except ImportError` was NOT the fix I claimed last round. ImportError also
covers a broken dependency inside an INSTALLED gateway; review probed
`ImportError.name = "gateway.relay.dependency"` and got an authorized
verdict. Now only a name identifying the gateway relay module itself is
absence. An ImportError with NO name stays absence — refusing on a fault we
cannot attribute would trade an unidentifiable bug for a real CLI/cron
outage, and an existing test caught exactly that when I first got it wrong.
#3 `relay_routed_platform` lowercases the requested platform; `_relay_fronted`
returned configured names verbatim. A platform configured as "Discord"
missed the membership test, looked native, and skipped the guard:
'discord' => refused 'Discord' => ALLOWED 'DISCORD' => ALLOWED
An attestation bypass on a string comparison.
UNDELIVERABLE PROMPTS THAT HUNG
#4 `_clarify_send_disposition` handled `failed` and `ambiguous` but not
`declined`, so a REFUSED clarify card fell through to wait_for_response and
blocked until clarify_timeout — indefinitely when configured non-positive.
A decline is more definitive than a failure, not less.
#5 The exec-approval decline branch returned quietly, which suppressed the text
fallback (right) but left the CENTRAL approval entry pending (wrong) — the
dangerous command stayed blocked until the approval timeout. My comment
claimed the registration was torn down; only RelayAdapter's private map was.
It now raises `_ExecApprovalDeclined`, which propagates to
`_await_gateway_decision`'s existing notify-failure path (drops the entry,
unblocks the tool). A dedicated type, re-raised past the local
`except Exception` that would otherwise have restored the leak.
#7 THE GAP THAT LET ALL OF THIS SHIP. Both caller-level suppressions were
unfalsifiable: deleting either branch left 36/38 tests green. The suites
drove `_approval_send_outcome` and `RelayAdapter` but never the real
TurnRunner / busy-session callers, so nothing observed whether a text send
FOLLOWED a decline — which is the whole property.
tests/gateway/test_decline_fallback_suppression.py drives both real callers
and records every send. Each decline case is paired with an ordinary-FAILURE
control, because without one a caller that never falls back would also pass.
MUTATIONS (all on production source, anchors count-checked, restored after)
#1 seal decline -> plain send KILLED
#1b seal drops raw_response KILLED
#2 nested ImportError -> authorized KILLED
#3 fronted set not normalized KILLED
#4 clarify declined branch removed KILLED
#5 approval decline returns not raises KILLED
#6 task_card drops raw_response KILLED
#7 slash-confirm suppression removed KILLED
#7's two were the reviewer's SURVIVORS (36/38 passing); both now die.
425 passed, zero failures.
* fix(relay): close the three round-4 blockers
Round 4 confirmed six of seven round-3 fixes and found three more. Each
reproduced before fixing, each mutation-checked after.
1. A NAMELESS ImportError still authorized. Last round I admitted it as
"absence" to protect the CLI/cron path. That reasoning was WRONG and the
interpreter says so:
import gateway.relay.nope -> ModuleNotFoundError, name="gateway.relay.nope"
import totally_absent_pkg -> ModuleNotFoundError, name="totally_absent_pkg"
Genuine absence is ALWAYS ModuleNotFoundError with `.name` set, so the
CLI/cron path never produces a bare ImportError and nothing legitimate was
being protected. A plain or nameless ImportError comes from an import hook
or a module that failed while initializing — an unattributable FAULT.
Now: absence is ModuleNotFoundError naming gateway / gateway.relay /
gateway.relay.egress; everything else refuses. Two existing tests raised a
bare ImportError to simulate absence and were corrected to the real shape.
2. SESSION ATTESTATION INVENTED IDS. `_session_ids` split every id on the first
colon to recover "chat" from "chat:thread". Matrix ids contain a colon
natively, so `!room:server.org` attested a bare `!room` — the guard
vouching for a destination on its own fabrication. The split now applies
only to platforms whose ids genuinely carry a `:thread` suffix (allow-list;
unknown platforms are treated as un-splittable, which can only refuse more).
Kept a Slack control: dropping the split entirely would refuse legitimate
thread replies, which is the outage the split exists to prevent.
3. THE TASK-CARD FIX WAS UNFALSIFIABLE — my own round-3 mistake, and the same
one round 3 caught me making. I added the production branch AND a test, but
the test stopped at RelayAdapter: it proved `raw_response` is carried and
never called `TurnRunner._task_card_publish`, which owns the property.
Deleting the real branch left 30 tests green. Now driven through the real
caller, with an ordinary-failure control.
The lesson generalises: proving the DATA reaches the boundary is not proving
the CALLER acts on it. Every one of these decline fixes has two halves and
the second half is where the security lives.
Also closed the round-4 non-blocking finding: `gateway/relay/egress.py` has its
OWN import boundary, and the existing test intercepted the earlier import in
tools/send_message_tool.py, so it was never exercised. Mutating that classifier
to treat every ImportError as absence now dies.
MUTATIONS (production source, anchors count-checked, restored after)
R4-1 nameless ImportError -> authorized KILLED
R4-2 session split unconditional KILLED
R4-3 task-card caller branch removed KILLED (was SURVIVED)
egress classifier: any ImportError = absence KILLED
Also probed and found NOT a leak: a refused OPENING draft frame disarms the
stream and the turn-final goes out via `send`. That send is itself guarded and
the connector refuses it too, so no content is delivered — unlike the seal case
(round 3, #1) where the seal was the only check on that path.
452 passed, zero failures.
* fix(relay): recover the thread parent from thread_id, not a colon split
Round 4 blocker 2 was closed with an allow-list of platforms whose ids have no
native colon. Reviewing my own fix while round 5 ran, the allow-list is the
wrong mechanism: it NARROWS a guess instead of removing it, and it still gets
Matrix wrong the moment a Matrix session is thread-qualified
(`!room:server.org:$thr` -> split yields `!room`).
The structured field was there all along. `_session_entry_id` composes the id
as f"{chat_id}:{thread_id}" and the entry still carries `thread_id`
separately, so the parent is knowable EXACTLY: strip the known suffix, or add
nothing. No platform list, no guessing, correct for ids that contain colons.
Mutations:
back to splitting on the first colon KILLED
thread parent never recovered (over-refuse) KILLED
Both directions matter: the first invents attestations, the second refuses
legitimate thread replies.
One existing test (M25) asserted the right PROPERTY with a fixture that omitted
`thread_id` — a shape real entries never have. Fixture corrected, assertions
untouched.
453 passed.
* fix(relay): close the four round-5 blockers
Each reproduced before fixing, each mutation-checked after.
R5-1 A DISABLED NATIVE ADAPTER BYPASSED AUTHORIZATION. `_has_live_native_adapter`
treated any entry in the adapter map as native; `resolve_delivery_transport`
ignores a native adapter whose config is disabled and routes over Relay.
Two independent routing classifiers, disagreeing:
guard says native: True delivery routes relay: True
So the guard skipped authorization for a send that went over the relay.
The guard now applies the router's enabled-state rule; probed both
configurations and they agree.
R5-2 THREAD IDS WERE NEVER AUTHORIZED. The parser splits chat_id and thread_id;
only chat_id reached the guard. On Discord the thread IS the destination —
`POST /channels/{thread_id}/messages` — so an attested parent channel
authorized an arbitrary caller-supplied thread. `authorize_relay_target`
now takes thread_id and requires its own attestation (bare id or the
`chat:thread` form a session origin produces); both call sites forward it.
R5-3 A DECLINED **INITIAL** DRAFT WAS RETRIED AS A PLAIN SEND. Round 3 fixed the
declined SEAL; the declined OPEN was a different path. `send_draft`
returned a bare failure, so the stream consumer read "draft transport
unusable", disabled drafts and fell through to `_first_send`. Measured
through the real adapter and real StreamTransportMixin:
before: ops ['draft', 'send'] after: ops ['draft']
send_draft now carries raw_response; a decline is terminal for the run and
the guard sits in `_first_send`, where every fallback path converges.
R5-4 MY ROUND-4 TASK-CARD FIX SUPPRESSED EXACTLY ONE UPDATE. It set
`native_failed`, which the entry gate already uses for an ordinary broken
lane, so the next progress event skipped the decline branch and went
straight to the text fallback:
after first publish: [] after second: ['send']
Terminal declines are now a separate `egress_declined` state checked at the
entry gate. A refusal does not expire after one tick.
MUTATIONS
R5-1 disabled native counts as native KILLED
R5-2 thread_id not authorized KILLED
R5-2b tool does not forward thread_id KILLED (was SURVIVED)
R5-3 initial-draft decline not terminal KILLED
R5-3b _first_send guard removed KILLED
R5-4 declined state not persistent KILLED
R5-2b is the same gap that produced findings 3 and 4 of the last two rounds, a
third time: every test called `authorize_relay_target` directly, so dropping the
argument from the TOOL WRAPPER changed nothing. Testing the callee never proves
the caller uses it — now pinned explicitly.
Each fix ships with an ordinary-failure control, because every one of these
makes the guard refuse MORE, and over-refusal is now the larger risk.
474 passed, zero failures.
* refactor(relay): declare the terminal-decline state where it lives
Both terminal-decline flags were set dynamically. They worked (neither class is
frozen or slotted) but an undeclared attribute hides the state from anyone
reading the class, and this one is security-relevant.
_TaskCardState.egress_declined — declared dataclass field
StreamConsumer._egress_declined — initialised in __init__
Lifetime verified while checking whether a refusal can leak ACROSS turns and
mute a healthy destination: it cannot. _TaskCardState is constructed per
progress-drain (run_turn_runner.py:420) and the consumer's flags per run
(stream_consumer.py:163), so both are fresh each turn.
Also verified the guard's blast radius after adding thread authorization: the
ONLY callers of authorize_relay_target are the two model-facing send_message
call sites. Gateway-internal sends — notably the handoff path, which creates a
thread and immediately posts to it with no session provenance yet — go through
transport.adapter directly and are unaffected. That was the most plausible
over-refusal, and it does not reach this guard.
461 passed.
* fix(relay): close the four round-6 blockers — the edit lane
R6-1 MY OWN R5-1 FIX REINTRODUCED THE BYPASS IT CLOSED. I wrote
`except Exception: return True` around the config lookup, so a config read
fault declared the platform native while the ROUTER, reading the real
config, sends over the relay:
guard_has_live_native True guard_verdict None router relay
Routing we cannot determine is UNKNOWN. It now raises RelayRouteUnknown,
which the outer handler must re-raise rather than flatten to False, and
`authorize_relay_target` turns into a refusal. This is the second time a
convenience `except` in this function created a bypass; there is now no
permissive return left in it.
R6-2/3/4 THE NINTH LANE: `edit`. ONE dropped field, THREE leaks.
`RelayAdapter.edit_message` discarded the connector response, and three
independent callers read a bare edit failure as "editing is unavailable"
and re-send the content as a NEW message to the same chat:
stream edit fallback ['edit', 'edit', 'send'] the unseen tail
queued reconciliation ['edit', 'send'] the WHOLE response
task-card fallback ['edit', 'send'] the task text again
Fixed at the source (edit_message carries raw_response) plus each caller:
`_on_edit_failure` — the single funnel for stream edit failures — makes a
decline terminal for the run, `_send_fallback_final` refuses to deliver a
continuation after one, the queued reconciler returns instead of sending,
and the task-card fallback sets the same terminal state R5-4 introduced.
R5-4 fixed the native task-card op and I did not check its sibling
fallback path. The pattern across rounds 3-6 is consistent: the fix goes
where the decline is OBSERVED, and the leak lives wherever someone else
later decides to retry.
MUTATIONS
R6-1 config fault -> assume native KILLED
R6-1b RelayRouteUnknown swallowed as False KILLED
R6-2 edit drops raw_response KILLED
R6-2b edit-failure decline not terminal KILLED
R6-3 queued reconcile falls back on decline KILLED
R6-4 task-card fallback edit decline KILLED
Each with an ordinary-failure control: a genuinely un-editable message must
still be delivered, and a broken card lane must still reach the user.
481 passed, zero failures.
* fix(relay): add a terminal-decline latch at the adapter choke point
THE STRUCTURAL FIX, not a twelfth local check.
Rounds 3-6 of review found ONE defect in eleven lanes: the connector refuses an
op, and some caller downstream reads that as 'this lane is unavailable' and
retries the same content through a DIFFERENT op against the SAME chat. Media,
prompt, draft-open, draft-seal, native task card, task-card fallback edit,
slash-confirm, exec-approval, clarify, stream edit, queued reconciliation.
Each was closed by adding a check at one more call site. That approach cannot
converge: gateway/ has ~60 outbound call sites, every one of them a place a
future change can reintroduce this, and four consecutive review rounds each
found another. The reviewer's own count of lanes is the argument against the
per-site design.
Every relay frame from every one of those callers passes through
_transport.send_outbound. One latch there covers them all: once the connector
refuses a chat, this adapter stops emitting CONTENT frames for that chat.
Proven to subsume the local checks: with the stream-edit per-site check
DISABLED, the leak probe still reports blocked=true — the frame never reaches
the wire. The local checks stay as defence in depth and for their better error
messages, but they are no longer the only thing standing between a decline and
a re-addressed send.
Scope is deliberately narrow, and each limit is mutation-pinned:
per CHAT - a refusal must not mute other conversations
CONTENT ops - typing/delete carry nothing; latching them would leave a
stuck typing indicator for no security gain
self-healing - cleared when the connector accepts that chat again, so a
transient policy change does not need a restart
Mutations:
latch never set KILLED
latch never consulted KILLED
latch is global, not per-chat KILLED
latch never clears KILLED
485 passed.
* fix(relay): one route source; the latch already covered round 7's lanes
Round 7 reviewed 573e41e294 — one commit BEFORE the terminal-decline latch —
and independently reached the same conclusion I had: 'The per-call-site
approach is structurally wrong. Use one turn-scoped choke point.' That is the
latch in 6dbc004594.
Its four 'still broken' lanes (tool-progress edit, progress-overflow edit,
long-running heartbeat edit, stale streamed-final reconciliation) all share the
shape edit_message->declined->adapter.send(same chat, same content), and NONE
has a local check. Probed all four against the latch:
tool_progress ops ['edit'] blocked
progress_overflow ops ['edit'] blocked
heartbeat ops ['edit'] blocked
stale_final ops ['edit'] blocked
That is the argument for the choke point, measured: lanes nobody patched are
safe anyway. Pinned by a parametrized test named for those four lanes.
R7-1 IS A REAL BYPASS THE LATCH DOES NOT COVER, and it is fixed here. The guard
rebuilt routing from GATEWAY_RELAY_PLATFORMS while resolve_delivery_transport
asks the CONNECTED adapter (fronts_platform, from the handshake identity set).
Different snapshots: with env discovery stale or momentarily empty, the guard
said 'native' and the router sent over the relay, skipping authorization.
before: guard_relay_routed False / delivery relay
after: guard_relay_routed True / delivery relay / unattested target refused
The guard now asks the live adapter first and falls back to config only when
there is no runner (CLI/cron) — pinned in both directions.
R7-5 (non-blocking, and a fair hit): my stream-fallback test asserted
_egress_declined and never drove _send_fallback_final, so removing that early
return SURVIVED. The test now calls the real fallback and asserts the wire is
untouched; the mutation dies.
Mutations:
R7-1 guard ignores the live adapter KILLED (was SURVIVED)
R7-5 fallback early return removed KILLED (was SURVIVED)
latch not consulted KILLED
491 passed.
* fix(relay): close three holes found by attacking my own latch
Round 8's brief told the reviewer to attack the latch. I did the same in
parallel and found three real holes in it before the review returned.
1. send_for_platform BYPASSED THE LATCH ENTIRELY. It builds and posts its frame
directly rather than through _outbound — and it is the delivery resolver's
OWN entry point, so it is the single most important caller.
before: ops ['edit', 'send'] after: ops ['edit']
gateway/AGENTS.md states the rule I had just broken: 'Seal-interception
exists at BOTH egress doors (send() and send_for_platform()); a new egress
door needs the same two checks.' The latch is a third such check and I had
wired it to one door.
2. A COSMETIC SUCCESS CLEARED THE LATCH. Clearing on ANY success meant a
typing indicator — routinely allowed for a chat whose content is refused —
re-opened the door for the very next send:
ops ['edit', 'typing', 'send']
Only a CONTENT op the connector accepted may clear it now.
3. A THREAD INSIDE A REFUSED CHAT WAS NOT COVERED. A thread lives inside its
parent, so the same content reached the same conversation one level down:
ops ['edit', 'send']
The latch key now strips the thread suffix.
Also normalised int/str chat ids (callers pass both; a type mismatch would
silently unlatch).
MUTATIONS
send_for_platform not latched KILLED
cosmetic success clears the latch KILLED
thread suffix not stripped KILLED
draft-seal retry not latched SURVIVED — EQUIVALENT, proven:
is unreachable while latched (a declined edit before the seal
produces ZERO seal frames, measured). Kept as defence in depth because it
posts directly, and documented at the site rather than covered by a
test that could not fail.
One self-inflicted bug on the way: a blanket replace put 1Password CLI brings 1Password to your terminal.
Turn on the 1Password app integration and sign in to get started. Run
'op signin --help' to learn more.
For more help, read our documentation:
https://www.1password.dev/cli
1Password CLI is built using open-source software. View our credits and
licenses:
https://downloads.1password.com/op/credits/stable/credits.html
Usage: op [command] [flags]
Management Commands:
account Manage your locally configured 1Password accounts
connect Manage Connect server instances and tokens in your 1Password account
document Perform CRUD operations on Document items in your vaults
events-api Manage Events API integrations in your 1Password account
group Manage the groups in your 1Password account
item Perform CRUD operations on the 1Password items in your vaults
plugin Manage the shell plugins you use to authenticate third-party CLIs
service-account Manage service accounts
user Manage users within this 1Password account
vault Manage permissions and perform CRUD operations on your 1Password vaults
Commands:
completion Generate shell completion information
inject Inject secrets into a config file
read Read a secret reference
run Pass secrets as environment variables to a process
signin Sign in to a 1Password account
signout Sign out of a 1Password account
update Check for and download updates.
whoami Get information about a signed-in account
Global Flags:
--account account Select the account to execute the command by account shorthand, sign-in address, account ID, or user ID. For a list
of available accounts, run 'op account list'. Can be set as the OP_ACCOUNT environment variable.
--cache Store and use cached information. Caching is enabled by default on UNIX-like systems. Caching is not available on
Windows. Options: true, false. Can also be set with the OP_CACHE environment variable. (default true)
--config directory Use this configuration directory.
--debug Enable debug mode. Can also be enabled by setting the OP_DEBUG environment variable to true.
--encoding type Use this character encoding type. Default: UTF-8. Supported: SHIFT_JIS, gbk.
--format string Use this output format. Can be 'human-readable' or 'json'. Can be set as the OP_FORMAT environment variable.
(default "human-readable")
-h, --help Get help for op.
--iso-timestamps Format timestamps according to ISO 8601 / RFC 3339. Can be set as the OP_ISO_TIMESTAMPS environment variable.
--no-color Print output without color.
--session token Authenticate with this session token. 1Password CLI outputs session tokens for successful 'op signin' commands when
1Password app integration is not enabled.
-v, --version version for op
Run 'op [command] --help' for more information on the command. into
send_for_platform, which has no such variable. Two existing unfurl tests caught
it — NameError at adapter.py:1407.
504 passed.
* fix(relay): Telegram handle exemption + a turn boundary for the latch
Round 8 blockers. Two of its four were already closed by 93750e351a (it
reviewed the commit before it); these two are real and both are mine.
B1 — THE TELEGRAM @HANDLE EXEMPTION COVERED A NATIVE SEND.
_is_unresolved_handle exempts telegram @handles from attestation because
"the connector resolves and authorizes it". That justification is FALSE
whenever the gateway holds its own token: _send_to_platform calls
_send_telegram(pconfig.token, ...) directly and no connector is involved.
So an unattested @handle went out under the gateway's own credential
while the numeric control was correctly refused.
The exemption now requires that no native credential exists. A probe
fault WITHDRAWS the exemption (falls back to the ordinary attestation
check) rather than granting it.
Shipped with the converse control: relay-only config still exempts
@handles, and numeric targets stay guarded in both modes.
B4 — THE LATCH HAD NO BOUNDARY, SO IT WAS AN OUTAGE MECHANISM.
My own regression, and worse than reported. Removing "clear on cosmetic
success" (correctly) removed the ONLY way the latch could ever clear: a
content op can never reach the connector to succeed, because the latch
blocks it locally first. A refusal at 09:00 muted that chat forever.
A new inbound message for a chat is the generation marker — the natural
teardown point. Suppression still holds for the whole turn.
same_turn_blocked: true next_turn_delivered: true
MUTATIONS (all killed)
handle exemption ignores native credential
native-credential fault GRANTS the exemption
no turn boundary (latch never clears)
teardown clears ALL chats not just this one
teardown ignores the chat
The last two SURVIVED first: I tested _clear_declined_for_turn directly
and never proved _on_inbound calls it — the caller-level gap that has now
produced four blockers on this branch. Added a test driving the real
inbound entry point.
One self-inflicted bug, caught by my own fault test: the probe imported
load_config, which does not exist (it is load_gateway_config), so it
always threw and returned the fault default. The test that pinned fault
behaviour is what exposed it.
510 passed.
* fix(relay): correct latch identity and boundary; one config snapshot
Round 9, four blockers, all reproduced.
B1+B4 — THE TEARDOWN WAS AT THE WRONG PLACE, twice over.
It sat on the adapter's raw _on_inbound, which runs BEFORE profile
routing, the ignored-channel guard, plugin hooks and user authorization.
An unauthorized or dropped event could therefore clear a refusal
belonging to an active turn, and stale content then went out as a
different op. The same placement missed Discord interaction passthrough,
which builds its own MessageEvent and calls handle_message directly, so
slash commands and modal submits stayed muted after an earlier decline.
Both are one mistake: I picked a lane instead of a boundary. Teardown now
runs immediately after _hm_admit_event, the single admission gate every
entry path shares.
dropped event -> latch survives, stale send blocked
admitted event -> latch clears
B2 — THE LATCH KEY SPLIT ON ':', WHICH IS A MISTAKE I ALREADY FIXED ONCE.
_latch_key did str(chat_id).split(":", 1)[0], so !room:tenant-a and
!room:tenant-b both keyed !room: a decline in one Matrix room muted
another, and inbound from one cleared the other's refusal. egress.py
::_session_ids stopped doing exactly this in round 4 and I reintroduced
it three rounds later.
Parent identity is never recoverable from identifier TEXT. Thread
coverage is now structural: _thread_parent looks the relationship up in
the recorded auto-thread map.
B3 — AUTHORIZATION AND DISPATCH USED DIFFERENT CONFIG SNAPSHOTS.
_handle_send retains one pconfig; the guard independently reloaded
config. Across a transition the authorization snapshot could see a
connector-only setup (exemption granted) while dispatch still held the
native token and sent the unattested @handle itself. The guard now takes
native_token from the SAME snapshot dispatch will use. A caller that
omits it does not silently look like "no token".
NB-1/2/3 also closed: real-object snapshot tests, an exception shield
that faces a real exception, and send_follow_up no longer discards the
connector's verdict (that discard is exactly how the edit lane laundered
declines).
MUTATIONS (all killed)
latch key splits on colon again
thread parent lookup disabled
dispatch token ignored by guard
tool drops the snapshot token
admission teardown removed
teardown moved BEFORE admission
exception shield removed
follow_up drops raw_response
"admission teardown removed" SURVIVED first: I had tested the helper, not
_handle_message. Added a test driving production _handle_message with
admission stubbed both ways. Fifth caller-level gap on this branch.
One self-inflicted bug caught before commit: I passed pconfig.token in
_handle_react, which has no pconfig — a NameError on every reaction.
516 passed.
* docs(relay): pin the latch's thread coverage limit as a deliberate trade
_thread_parent only sees connector auto-threads, and that map is capped at
256 entries, so a user-created or evicted thread does not inherit its
parent's latch. Documented at the site and asserted by a test, because the
alternative - deriving parents from identifier text - is exactly what muted
unrelated Matrix rooms in round 9.
The primary control is unaffected: authorize_relay_target takes thread_id as
part of the destination and attests it on every send (6 thread tests).
* refactor(relay): one SendResult decline classifier for all 8 gateway lanes
The extraction found a DEFECT, not just repetition.
Eight gateway lanes each hand-rolled the unwrapping of a decline from a
SendResult, and they did not agree. Six checked only raw_response. Two
also checked the error text. A connector that answers with the uniform
decline SENTENCE and no structured code - the documented contract for
older connectors, per _approval_send_outcome - was therefore classified
as an ordinary failure by those six lanes, so each treated a refusal as
"editing unavailable" and retried through another op.
Measured:
text-only decline six-site check False two-site check True
structured decline six-site check True two-site check True
No content leaked, because the adapter latch classifies the transport
dict directly and catches both shapes (verified: text-only decline still
latches C1 and keeps SECRET off the wire). The cost was wrong verdicts
and futile retries, not disclosure.
declined_send(result) in gateway/relay/egress.py now owns this. It checks
raw_response when structured, else the error text, and preserves the
ambiguous exclusion - an ambiguous result is a transport outcome, so it
must never read as a refusal.
run.py keeps its own shape deliberately: that lane has three verdicts
(ambiguous / declined / failed), so it checks ambiguous first and then
delegates the boolean.
MUTATIONS (all killed)
helper drops the text-only branch
helper drops the structured branch
ambiguous no longer excluded
draft lane decline check removed
edit-failure lane decline check removed
prompt verdict lane check removed
slash-confirm lane check removed
draft lane goes terminal on ANY failure (over-refusal direction)
"draft lane decline check removed" SURVIVED first: _send_draft_frame had
no test driving an unsuccessful send_draft at all. Added one, with an
ordinary-failure control so the fix cannot silently become "one flaky
frame mutes the chat". A non-unique anchor also masked the edit-failure
lane on the first pass - the trap my own skill warns about.
This closes the duplication that caused four of nine rounds of blockers:
a new lane now calls one classifier instead of copying three lines.
519 passed.
* fix(relay): latch identity, new-turn boundary, seal arming, ambiguity
Round 10, four blockers, each reproduced before fixing. Two are my own
regressions from the previous two rounds.
B1 - ADMISSION IS NOT A NEW-TURN BOUNDARY.
Round 9 moved teardown to just after _hm_admit_event. That is only an
ADMISSION gate: an authorized message can be steered into a running
session, answer a pending prompt, run a busy slash command, or be refused
by the pause/drain gates - all without starting a turn. Each of those
cleared the ACTIVE turn's refusal, and a later fallback from that turn
reached the wire (probe: latch emptied, wire ops ['edit', 'send']).
Teardown now runs after _claim_active_session_slot, the first point the
runner OWNS a new turn. The new test drives production _handle_message
through all four non-turn lanes plus the real new-turn path.
B2 - LATCH IDENTITY OMITTED THE LOGICAL PLATFORM.
One relay adapter fronts several platforms, so native ids collide. A
Discord refusal for chat 42 was cleared by clear_egress_latch("telegram",
"42") - the method took a platform and ignored it - and the Discord
fallback then reached the connector. Keyed by normalized platform plus
exact chat id; thread-parent expansion keeps the platform component.
B3 - THE DIRECT DRAFT-SEAL PATH DID NOT ARM THE LATCH.
_seal_open_draft posts through _attempt directly rather than _outbound,
so a definite decline logged and returned but never latched. The
immediate plain-send fallback was suppressed by the caller's own check;
later same-turn sends were not (wire ['draft', 'draft', 'send'], the
third frame carrying refused content).
B4 - MY OWN REFACTOR MADE AMBIGUOUS RESULTS TERMINAL.
send_draft's ambiguous projection discarded raw_response, so
declined_send fell through to the error-text branch - and an ambiguous
result whose text carries the decline marker ("... egress declined: ack
lost") read as a DEFINITE refusal and terminated the run. Ambiguous means
the frame may well have been delivered: a transport outcome, never an
authorization one.
Fixed on both layers: the projection carries the body (and the seal's
ambiguous return is now explicit too), and declined_send's text-only
branch - which cannot see the ambiguous flag - treats ack-lost text as
transport ambiguity. Audited every SendResult projection in adapter.py
for the same shape.
MUTATIONS (all killed)
latch key drops the platform
clear_egress_latch ignores platform
draft seal does not arm the latch
ambiguous projection drops raw body
declined_send infers decline from ack-lost text
teardown back at admission
523 passed.
* refactor(relay): split the terminal-decline latch out of the guard PR
The latch moves to feat/p5-egress-decline-latch (pushed at 3cf45736d7,
which retains the full history) for redesign. This PR keeps the
authorization guard and the per-site decline checks.
WHY. Across eleven review rounds the two halves behaved very differently.
The guard is a PURE FUNCTION of the destination - its blockers were all
"you asked the wrong question" (case sensitivity, nested ImportError,
missing thread_id, config snapshot skew), each a one-line correction that
then stayed fixed. Rounds 7-10 found nothing new in it.
The latch is MUTABLE STATE WITH A LIFETIME living on RelayAdapter - an
object registered once per process that holds the WebSocket and has no
concept of a turn. Nine of its blockers reduce to three questions the
adapter cannot answer: when does it end, who arms it, what is it keyed
on. Every answer so far has been a proxy (a successful op, an inbound
message, an admitted event, a claimed session slot) and every proxy was
wrong in a lane found later.
The per-site checks hold identical information on `st` - a PER-TURN
object - and have produced zero blockers, because the state dies with the
turn and nobody has to decide when it ends.
The no-relaunder property does NOT depend on the latch. Measured on the
real consumer path with the latch absent: a declined draft frame sets
_egress_declined and puts nothing on the wire.
Removal verified structurally rather than by eye: an AST diff of every
symbol between HEAD and this tree reports only latch symbols gone,
nothing added. That check caught two over-deletions my strip made -
_on_inbound (consumed by a "next def" boundary) and _SEEN_INBOUND_MAX
(a class constant inside the removed span). Both restored; 19 failures
went to 0.
ALSO: RESTORED A TEST I WRONGLY REPORTED AS PASSING.
test_tool_guard_forwards_thread_id never made it into the repo - `git log
-S` finds it in no commit - though round 5 recorded its mutant as killed.
Dropping thread_id from the guard call therefore survived the entire
tests/tools suite (146 passed). Written properly this time, driving the
real _handle_send far enough to reach the guard. It now KILLS that
mutant.
MUTATIONS on this tree
guard fault authorizes instead of refusing KILLED
thread_id dropped from the guard call KILLED (was SURVIVED)
handle exemption ignores native credential KILLED
draft lane decline check removed KILLED
prompt verdict lane check removed KILLED
slash-confirm lane check removed KILLED
503 passed.
* test(relay): close the phantom-coverage gaps the guard audit found
The thread_id test that was reported as killing a round-5 mutant turned
out never to have been committed. That is a reason to distrust the other
claimed kills, so I re-ran every guard mutation against the COMMITTED
tree instead of trusting the earlier reports.
Result: 9 of 11 killed, and the two "SKIPPED" ones had non-unique
anchors hiding SIX separate sites. Mutating those individually found
three real survivors.
CASE NORMALISATION (round 3, finding 3) WAS HALF-COVERED.
test_relay_fronted_matching_is_case_insensitive varies the CONFIGURED
name but always requests lowercase "discord", so it pins _relay_fronted's
normalisation and nothing else. The REQUESTED name's `.lower()` was
covered by nothing at all. Probe with it removed:
relay_routed("Discord") -> False
authorize("Discord", unattested) -> AUTHORIZED
which is exactly the bypass round 3 reported, alive again and untested.
Two further sites were untested in the OVER-REFUSAL direction: the
attested store is keyed lowercase, so a mixed-case request missed its own
attested set and refused legitimate traffic. attested_relay_targets' own
normalisation was invisible to every existing test because they all
monkeypatch that function away; it is now asserted against the real
function with only its leaf sources stubbed.
Three tests added. All six case sites now die when mutated.
I also re-did the three fail-closed RelayRouteUnknown mutations properly.
The first pass swapped whole lines and produced IndentationErrors, so
"KILLED" there proved nothing but a syntax error. Neutralising each raise
at correct indentation: all three genuinely KILLED.
FINAL AUDIT ON THIS TREE — 17 mutations, zero survivors
guard: thread_id dropped at the call site
guard: react path unguarded
guard: handle exemption ignores native credential
guard: 3x fail-closed raise neutralised
guard: 6x case-normalisation site
classifier: ambiguous treated as a decline
classifier: text-only decline branch removed
lane: draft / stream-edit / prompt / slash-confirm checks removed
511 passed.
* test(relay): make the stream-edit test fail for the right reason
Review of 45835a282d raised one blocking issue and three non-blocking
ones. All four are addressed; none was a production defect.
BLOCKING — the stream-edit test failed on the double, not on a leak.
test_declined_stream_edit_does_not_send_the_unseen_tail implemented only
the GUARDED path in its consumer double. Removing either guard therefore
raised AttributeError inside the fake before any send could be observed:
guard 1 removed -> AttributeError: no attribute '_is_flood_error'
guard 2 removed -> AttributeError: no attribute '_clean_for_display'
Red, but for the wrong reason — the test could not have caught the leak
it is named for. My own docstring claimed it drove the fallback and
checked the wire; it did neither.
The double now implements everything the UNGUARDED path reaches
(_is_flood_error, _flood_strikes, _current_edit_interval, _last_edit_time,
_notify_new_message, _try_strip_cursor, _clean_for_display,
_fallback_prefix, _metadata_for_send). Both mutations now fail on real
assertions:
guard 1 removed -> assert consumer._egress_declined is True
guard 2 removed -> AssertionError: the unseen tail reached the wire:
['send']
NON-BLOCKING 1 — a docstring claimed more than the test exercises.
test_requested_platform_name_is_also_normalised described a mixed-case
send_message(target="Discord:999") bypass. That entry point cannot reach
it: _resolve_tool_target lowercases the platform at
tools/send_message_tool.py:47 before the guard runs. The test still pins
a real contract — the helpers must not assume a lowercased argument, for
the gateway lanes and any future non-normalising caller — so the claim is
narrowed to that rather than the test removed.
NON-BLOCKING 2 — the module docstring said "every lane drives the REAL
RelayAdapter". The stream tests drive mixin doubles by design, because
the behaviour under test belongs to the adapter's CALLER. Docstring now
distinguishes the two kinds.
NON-BLOCKING 3 — latch-deletion residue in gateway/relay/adapter.py:418:
return None
return latched if surface_declines else None
The second line was unreachable and referenced a name deleted with the
latch. Removed, along with the 20-line comment block describing the latch
as "the structural fix" — that mechanism now lives on
feat/p5-egress-decline-latch, not here.
The reviewer independently confirmed the large deletion: an AST census
between 3cf45736d7 and f57a2298fa reports only latch symbols removed and
nothing added.
511 passed.
* docs(relay): correct three claims that outran the code
Review of 41ce3cc765 found no new production defect but three overstated
claims, one of them in my own commit message.
1. THE LATCH COMMENTARY WAS STILL THERE. My previous commit message said
it removed "the 20-line comment block describing the latch as the
structural fix". It removed only the unreachable statement. Twenty
lines at adapter.py:361-380 still described a per-chat latch, a choke
point and its scope rules - none of which exist on this branch. In a
refusal-sensitive module that reads as coverage this branch does not
have. Now removed for real.
This is the same defect class as the tests: a claim that outran what
the code does. I made it while fixing that class.
2. THE STREAM-TEST DOCSTRING OVERSTATED BOTH MUTANTS. It said the
mutation "now fails on the assertion that a send reached the wire" -
true of one guard, not both. Verified separately:
remove the _on_edit_failure check -> dies on _egress_declined,
never reaches the fallback
remove the fallback early return -> dies on the wire: ['send']
Both are valid behavioural failures, which is what the blocker asked
for; they are different observables and the docstring now says so.
3. Duplicate `from types import SimpleNamespace` from an earlier scripted
insert; imports reordered.
112 tests pass in the four focused files.
* fix(relay): close two authorization defects found in review
Both were reproduced before fixing and both mutants are pinned.
1. A LIVE relay adapter whose fronts_platform() raised degraded into the
config fallback. `_live_relay_fronted` returned None for every failure,
and None means "no live adapter, use the config snapshot" — so a faulting
adapter plus an empty/stale snapshot made the guard conclude "not
relay-routed" and authorize an unattested destination, while
resolve_delivery_transport asks that same adapter and still routes over
the relay. Measured: relay_routed=False, verdict None for chat 999.
Absence and fault now have separate return values: None only when there
is no runner or no relay adapter; a live adapter that cannot answer
raises RelayRouteUnknown. This is the third instance of this bug class in
this file, and the first two were also mine.
2. An attested chat whose id equalled the requested THREAD id vouched for
that thread. The `thread in attested` arm proved nothing about parentage.
Measured: attested {"-100A", "7"} authorized (-100A, thread 7).
Only the bound `parent:thread` form is accepted now. Nothing legitimate
needed the bare arm — _session_entry_id records a threaded origin as
f"{chat_id}:{thread_id}", and a thread addressed as its own channel
arrives as chat_id and passes the parent check.
The existing test blessed the bare form via parametrize, so it PINNED the
defect. Corrected, plus negative controls for the sibling-chat and
other-parent cases and a positive control proving genuine absence still
takes the config path (otherwise fix 1 would break native-only deploys).
Merged origin/main (was 22 behind). 428 passed via scripts/run_tests.sh;
full 10-row mutation ledger re-killed on the merged tree, none dying on an
exception rather than an assertion.
* fix(relay): only a missing adapter is absence; everything else is a fault
Reviewer BLOCKER, reproduced before fixing. Two more paths where a PRESENT
relay adapter still degraded into the config snapshot:
1. `fronts_platform` may be a property or descriptor, so the ATTRIBUTE
LOOKUP can raise — and the lookup sat inside the absence handler. Probed
with a raising property plus an empty snapshot: live=None, routed=False,
verdict=None, i.e. an unattested target authorized. The previous test made
an already-retrieved METHOD raise, so it could not reach this.
2. A present adapter with no usable `fronts_platform` returned None for the
same reason. An adapter that cannot say what it fronts is broken, not
absent, so it now raises too.
Also found by my own spot-check while the review ran: the nested imports of
`gateway.config` / `gateway.run` inside the live probe shared the broad
handler, so a broken installation degraded to the snapshot as well. Probed
with a healthy-adapter positive control in the same run — healthy refused
the unattested target, faulted authorized it. `_relay_fronted` one function
below already drew this exact distinction for its own import.
The boundary is now: `relay is None` is the ONLY absence. Everything about a
present adapter — attribute access, callability, the call itself, and the
imports needed to reach it — is a fault and raises RelayRouteUnknown.
This is the fourth variant of absence-vs-fault in this file and all four
were mine. The lesson is in the code as a comment rather than in a commit
message nobody re-reads.
Four controls keep genuine absence benign: no runner, no relay adapter in
the runner, a real ModuleNotFoundError naming the gateway package, and the
configured-attested-target-still-sends case.
434 passed via scripts/run_tests.sh; 9-row mutation ledger re-killed
including both new guards, none dying on an exception.
* fix(relay): invert the live probe to fail closed by default
Reviewer BLOCKER round 2, reproduced: reading the adapter registry can also
raise. A runner whose `adapters.get()` raised gave relay_present=True,
live=None, routed=False, verdict=None — unattested discord:999 authorized.
That was the FIFTH boundary in one function with the same defect: the call,
the attribute lookup, a non-callable attribute, the nested imports, and now
the registry lookup. Each round I patched the reported boundary and the
defect moved one statement up. The cause was the shape, not the statements:
the function asked "did something go wrong?" and answered None, and None
MEANS "no live adapter, use the config snapshot" — so every statement was a
new chance to fail open, and every new statement would have been too.
Inverted rather than patched a sixth time. Each `return None` now sits
behind an explicit narrow check that cannot itself be the fault (no runner,
no adapters, no relay key, gateway package genuinely absent), and one outer
handler turns anything else into RelayRouteUnknown. A statement added inside
this function is now fail-CLOSED by default.
Verified all six fault shapes raise (call, attribute, missing method,
registry .get, .adapters property, runner ref) and all five absence shapes
stay benign, plus a liveness control where the config snapshot disagrees
with a healthy adapter and the adapter still wins.
Four new tests, including the two absence controls that keep native-only and
CLI deployments working. 438 passed via scripts/run_tests.sh. Mutation
ledger: 8 killed. One survivor recorded as a proven equivalent mutant —
widening `if not registry` to `or {}` is behaviourally identical because
`{}.get()` returns None, i.e. the same absence; it is a readability guard.
* feat: add governed GitHub PR Hermes bridge
* fix: harden bridge PID probe and kernel race
---------
Co-authored-by: Ben Barclay <ben@nousresearch.com>
Co-authored-by: mrkillbob <mrkillbob@users.noreply.github.com>
Co-authored-by: Mike DeMott <25466867+mrkillbob@users.noreply.github.com>
elphamale
pushed a commit
to elphamale/hermes-agent
that referenced
this pull request
Sep 10, 2026
…#99220's egress-decline guard _send_draft_frame's retry/cooldown rewrite and NousResearch#99220's terminal declined_send() check both touched the same failure branch. Ported the retry/cooldown restructuring on top of the post-NousResearch#99220 body: an authorization decline is checked first and returns immediately (terminal, doesn't consume the retry budget); an ordinary failure falls through to the existing retryable/cooldown/failure-count logic. Also updates two NousResearch#99220 test doubles that pre-date the new _draft_cooldown_until/_last_draft_retryable attributes, and corrects a CONTROL assertion that still expected the pre-NousResearch#53865 single-strike disable behavior instead of the 3-strike retry budget.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this does
The
send_messagetool lets the model name a destination (platform:chat_id). This PR adds two things:sendorreact, the named destination is checked against the provenance this gateway actually holds — the channel directory and its own session origins. An unattested destination gets an explanatory refusal instead of a delivery.The egress path authenticated the sender but never authorized the destination. gateway-gateway #254 (merged,
82b2b05) closes the connector-side half; this is the agent-side half.Scope
25 commits · 15 files · +3,694 / −14 against current
main.gateway/relay/egress.py,tools/send_message_tool.pygateway/relay/adapter.py,run.py,run_busy.py,run_notifications.py,run_turn_runner.py,stream_consumer*.pyMerged
origin/mainateaae4fb8b6(was 413 behind; now 0). Four conflicted files were resolved by takingmain's structure and re-homing the fix into it —mainhad decomposed every file this touches. All eight decline guards verified present after the merge, and every mutation below was re-run on the merged tree.What is NOT here
The per-chat terminal-decline latch was removed from this PR (210 lines) and moved to
feat/p5-egress-decline-latchfor redesign. Review found the guard converging while the latch was not — nine of its blockers reduced to three questions the adapter cannot answer (when does it end, who arms it, what is it keyed on), because it put turn-scoped state on a process-lifetime object.Measured before removing it: with the latch absent, the real consumer path still puts nothing on the wire after a decline. The per-site checks hold the no-relaunder property on their own; the latch was defence in depth.
Mutation ledger
Every row re-run on the merged tree. Verdicts distinguish a genuine assertion failure from an exception/syntax failure — a mutant that dies inside a test double proves nothing.
thread_iddropped from the guard calltools/send_message_tool.py:250tools/send_message_tool.py:183@handleexemption ignores native credentialgateway/relay/egress.py:440gateway/relay/egress.py:218,240,280egress.py:301,378,483+_relay_frontedambiguousclassified as a declinegateway/relay/egress.py:65gateway/relay/egress.py:110gateway/run.py:759gateway/run_busy.py:1222gateway/run_notifications.py:350gateway/stream_consumer_transport.py:183gateway/stream_consumer_transport.py:519gateway/stream_consumer_fallback.py:83stream_consumer_transport.py:183511 tests pass in the focused selection; 112 in the four files a reviewer would run first.
Verification honesty
Three claimed kills in earlier rounds turned out to be phantom, and are worth stating plainly:
test_tool_guard_forwards_thread_idwas reported as killing a round-5 mutant but was never committed (git log -Sfinds it in no commit), so droppingthread_idsurvived the wholetests/toolssuite. Written properly; it now kills that mutant..lower()from the requested name restored the original bypass untested. Three tests added.test_declined_stream_edit_does_not_send_the_unseen_tailfailed onAttributeErrorinside its own double rather than on an observed send, so it could not have caught the leak it was named for. The double now covers the path the mutation opens; the two guards die on their own observables (_egress_declinedfor one,ops == ['send']for the other).Each was found by re-running the mutation ledger against the committed tree rather than trusting the earlier report.
Review history
Ten adversarial rounds under a dedicated reviewer profile; 30+ blockers closed, each reproduced before fixing.
andrexibiza's three blockers from the human review are closed. The most recent round found no blocking production defect.