Repository navigation
Add Always allow for a Bot or a group to tool approval cards - #544
Merged
Merged
Conversation
DSH's approval outcomes are one-shot, so a Bot asked for the same sandbox escalation every time. Keep the owner's standing grant on the Bot or the group and answer later matching approval/request asks with allowed-once from FlyBot's own answerer; revoke from Bot or Group settings. Fixes ThinkFlowLab#540
…proval # Conflicts: # core/client.js # patches/ds-bot/0003-flybot-api-client.patch # patches/ds-bot/0008-client-bundle.patch
…ab#540) Review found that a Bot's grant would also answer a turn a friend or another room member started, and that on a host nobody signed in to a group grant did not list or cover Bots made after the identity update. Check turn-origin before answering, and treat every local Bot as the one person's until authz is enforced.
…proval # Conflicts: # core/client.js # patches/ds-bot/0008-client-bundle.patch
Collaborator
Author
|
Verdict: PASS at Checked, line by line
Residual risks (for the owner)
|
github-merge-queue
Bot
removed this pull request from the merge queue due to a conflict with the base branch
Oct 20, 2026
Collaborator
Author
|
Self-review (review-pr, Birfy reviewer agent, 2026-10-20 21:20 Asia/Shanghai): PASS (merge-main conflict fix; no feature change) Tip SHA: be15d5f
Findings: none to act on. This review does not authorize a merge: risk:T3 still needs the maintainer's approval (the owner queues it). |
This was referenced Oct 20, 2026
Closed
Birfy
added a commit
to Birfy/FlyBot
that referenced
this pull request
Oct 20, 2026
Generated patches regenerated from the merged core/; topics.json keeps main's src/host/approvals.js and this branch's src/client/secret-card.js.
Birfy
added a commit
to Birfy/FlyBot
that referenced
this pull request
Oct 20, 2026
The merge queue run for ThinkFlowLab#551 failed "warnings are kept, cleaned, written to the log, and read back after a restart" with ENOENT on diagnostics.jsonl: the log is written in the background, and on a busy runner the write had not landed after the test's fixed 50 ms sleep. Neither ThinkFlowLab#551 nor ThinkFlowLab#544 touches diagnostics; a slowed mkdir reproduces the same ENOENT locally. Poll for both lines (up to 5 s) instead. Docs-not-needed: test-only timing fix, no behavior change.
Birfy
added a commit
to Birfy/FlyBot
that referenced
this pull request
Oct 20, 2026
…kFlowLab#551) A Bot that works on something handed out in a group (a member there sends it the work with `message_bot`) runs it in a hidden turn of its own chat. Its `ask_user` card therefore landed in the Bot's private chat, and an answer there never went back to the group. Now the card sits in that group's composer dock, named for the Bot that asks. The answer reaches the Bot as a hidden request from the member that handed the work over, so the Bot's reply goes back to the group the same way the work does. The group shows a quiet notice of the answer, and the Bot's private chat gets no card and no visible turn. Fixes ThinkFlowLab#550 - `tools.js`: `ask_user` in a turn that answers a group member's request (`senderRoomId`, not `audience: 'user'`, not a friend's) writes `state.questions[<room>]` (`header`, `botId`, `replyTo`, the turn's `origin`, `allowCustom`). Only one card per group: while one is open, a second Bot is told to ask in its reply. `rt.answerGroupQuestion` delivers the answer and posts the notice. - `channel.js` `answer-question`: routes a room card to it. `delivery.js`: a header for it (`answeredIn`). `turns.js`: a typed group line no longer clears the group's card. - `authz.js`: only the asking Bot's owner or the room's owner sees or answers such a card. A non-owner's answer carries `origin: other`. - `roster.js`: deleting the room or the Bot drops the card. Face-to-face rooms use the same path on the local home. - Docs: `core-host.md`. Changelog fragment `550-group-questions.fixed.md`. Not changed: `ask_user` inside a group Session is still refused (the Bot asks in its reply, which already shows in the group). Secret cards stay private. `reply_to: "user"` hand-offs are still answered in the Bot's own chat by design. ## Verification (tip 6dfe7ba) - The second commit, 6dfe7ba, runs the answerer's display name through `cleanName` before it goes into the group notice. - Red at base: 11f80dd with only `test/group-work.test.js` and `test/authz.test.js` copied in gives 4 fail / 27 pass. The 4 new ThinkFlowLab#550 tests fail and the own-chat guard test passes. At the tip they all pass. - `ARCH_DOCS_BASE=origin/main TZ=UTC npm run verify` passes: core 1121/1121, social 313, tree 83, timeline 93, scripts 93, interop 37, live-e2e 16; arch-docs OK; patches check ok. oxlint warnings are 53 at both base and tip. - On the first verify run (at 368b4fb), `tasks.test.js` "an untagged hold stamps the latest working task…" failed once under full-suite load. It passed 3 of 3 alone and the rerun was fully green. That test uses millisecond timestamps, and this PR does not touch that code. - DSH smoke (`dev/bench.sh` + `dev/smoke.mjs`, DSH 0.2.0-rc.2, mock model) passes all 42 steps at 6dfe7ba. Not run: Desktop app, a real model, a live two-home face-to-face run, and a browser check of the group dock rendering. The client is unchanged: `QuestionDock` already reads `questions[sessionId]` for the open conversation and shows `header`. File overlap with open PRs: ThinkFlowLab#544 touches `authz.js`, `channel.js`, `topics.json`, `core-host.md` and the 0001/0005 patches; ThinkFlowLab#547 touches `0001-core-fixes.patch`, `topics.json` and `core-host.md`. The source hunks are in different places. `topics.json` adds `test/group-work.test.js` to topic 0001. --------- Co-authored-by: Birfy <15378933+Birfy@users.noreply.github.com>
1 task done
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
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.
Fixes #540
Tool approval cards had only Reject / Allow once, and DSH's approval outcomes are one-shot (
ApprovalOutcome=allowed-once | rejected | cancelled | unavailable,ApprovalPolicy=ask | neverin@deepseek-ai/dsh-user-approval0.2.0-rc.2), so a Bot asked for the same sandbox escalation every time. Owner decision 2026-10-20 20:11 / 20:12 (Asia/Shanghai): permanent approval, per Bot and per group.What changes
core/src/client/member-status.jsApprovalCard,core/src/client/inbox.jsInboxCard) add Always allow for this Bot (此 Bot 始终允许) and, for an ask from a group, Always allow for this group (本群始终允许). Never on a friend's Bot.core/src/host/approvals.js): permission kind = tool + sandbox mode parsed from DSH's reason (bash:escalate:danger-full-access).approval-answertakesalways-bot/always-room; the grant is kept on the Bot / room record (standingApprovals, instate.json), and this ask plus other waiting asks it covers are answeredallowed-once. FlyBot'sapproval/requestlistener (documented waterfall, no DSH patch) answers later matching asks itself, only for a turn the owner started (turn-origin.jssettled() === 'owner'; friends' messages, other members' lines, rooms with other people and verdict-less turns still ask). A Bot grant covers the Bot's Sessions; a group grant covers the owner's Bots working in that group (not their own chats). DSH's audit pair still logs each ask.core/src/client/standing-approvals.js, endpointstanding-approval-remove).core/src/host/authz.js): analways-*answer needs the Bot's owner (owning the room is enough only for Allow once); removing a group grant needs the member who gave it, and removes only theirs.540-always-allow-approval.added.md.Risk tier: T3 (risk-gate:
core/src/host/approvals.js,authz.js,channel.js). Waits for the maintainer's approval; not merged by the agent.Verification (tip
f7e6a7e789005365befd6bb44d55f88d5871607a= b6236f8 merged with main at cf61952, Node 24.21)ARCH_DOCS_BASE=upstream/main TZ=UTC npm run verify: exit 0; core 1122/1122, plugins 313, 83, 93, 93, 37, 16 all pass; arch-docs OK (31 files); no new lint warnings.CONTEXT_WINDOW=100000 CHECK_RATIO=0.45 dev/bench.sh smoke 3196 8896 reset && node dev/smoke.mjs smoke 3196, DSH 0.2.0-rc.2): 42/42 atb6236f8; the merge tof7e6a7echanges only client files from Name a friend's Bot one way and approval cards by the receiving person #502,core/src/hostandcore/index.jsare identical.tasks.test.js"an untagged hold stamps the latest working task…" (also 1 of 6 isolated runs at this branch); that test and its code are untouched here: a pre-existing flake.Not run
f7e6a7e(host unchanged since the smoked tip).bashescalation (covered by unit tests with DSH'sescalate sandbox to <mode>: …reason format).