M4b: the redirect checked on the owner's server; finding 1 closed

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-24 12:29:02 -07:00
parent bfbdccb99d
commit ddb459a631
1 changed files with 15 additions and 0 deletions
@@ -667,3 +667,18 @@ The fault was the design model's, in M4a. Those two posts are two sessions, whos
 their own threads, so the order they reach `loopd` is up to the scheduler: under load, 1 run in 60
 failed. `mm_json.rs` already checks the order of catch-up, so the test now compares the two turns
 as a set (a43d997; 100 of 100 runs under load; tip T32).
 **Against the owner's server** (2026-09-24; the same stack as the first review's, built from
 `bfbdccb`). The second account, allowed to talk but not to approve, asked the bot in a direct
 message to read a file that the `ask` grant covers:
 | Claim | Seen |
 |---|---|
 | The approval goes to the first approver's direct messages, not the asker's | a new thread in the owner's direct messages; nothing answerable in the asker's |
 | Its first post says who asked, where, and their message | "**Approval 0** was asked by @<second account> in a direct message with the bot. Their message:", then the message, fenced |
 | The approval follows in that thread | the usual post: tool, fenced arguments, grant, taint, expiry, reply line |
 | The asking thread is told | "waiting for approval 0: it was sent to an approver" |
 | The approver answers in the new thread | `!approve 0` there; the post became "✅ Approved by @kyle: the call runs."; the audit log's approval names the owner and that reply's post id; `bxctl audit verify` ok, 3 records |
 | Task 16's sentence | the call was refused with "no tool runner is configured: brokerd.toml has no [runner] section", and the model passed it on to the asker |
 Finding 1 is closed.