[Ideas] 让 approval/request 对插件 ctx 可达（与 user-questions/request 对齐）

[clhui]

[Ideas] 让 approval/request 对插件 ctx 可达（与 user-questions/request 对齐）

一句话

approval/request 目前任何插件都观测不到、更无法应答，而 user-questions/request 可以。结果是：所有交互式审批 surface 只能活在宿主内部，第三方 surface（IM/手机、手表、语音、自定义 UI）在结构上就做不出来。我们希望有一个 seam 让插件参与审批 —— 具体场景是"在手机上审批"，但同一堵墙挡住的是所有宿主之外的 surface。

影响

用手机驾驶 dsh 会话的人能收到 round 卡、叙述和问询卡，唯独收不到审批卡。当某个工具调用需要提权而人不在电脑前时，回合只能等到审批超时、fail-closed 拒绝 —— 工作直接停住，而手机上没有任何办法把它放行。这是"用手机驾驶已有 dsh 会话"这条路上唯一缺的一块。

根因（dsh-desktop 0.2.0-rc.2 实测）

1. 请求由 approval service 自己的 events 实例派发（带 scope），不是从插件所挂的那个 surface 派发。
2. dsh-scope 的准入把插件 ctx 排除在外：无 tag 的监听器全局准入，带 tag 的只对匹配/祖先 scope 准入（hook.global || !filter || filter.call(thisArg, hook.ctx)）。插件的 ctx 是提问 agent 子树的兄弟，请求根本到不了它。
3. 宿主的 Web answerer 是阻塞式监听器 —— 它 await 浏览器，所以即使有插件监听器被排在它后面准入，也永远轮不到。

我们试过五种注册方式，在大量真实审批上一次都没有触发（每一次都由宿主自带 UI 处理）：插件 ctx、{ global: true }、{ global: true, prepend: true }、ctx.root.on(...)、ctx.get('approval').ctx.on(...)。

让这件事看起来像疏漏而非有意设计的，是这个对照：user-questions/request 能到达插件 —— 注册在已绑定 agent 的 ctx 上（ctx.on('user-questions/request', …)）即可，而这正是我们希望审批也具备的形态。今天问询卡在手机上工作正常，审批卡则完全不可能。

最小复现

1. 在 dsh 里加载一个插件，同时为 approval/request（上述五种变体）和 user-questions/request 注册监听器，进入时打日志。
2. 触发 ask_user_question → ask 监听器触发。
3. 触发一次提权工具调用（例如沙箱升级 / 向工作区外写文件）→ 审批监听器从不触发，由宿主 UI 单独应答。

环境：dsh-desktop 0.2.0-rc.2（Electron 44 / node 24.18.1）、dsh-skill 0.2.0-rc.2。

期望的 seam（任一即可解开）

1. 与 user-questions 对齐：让 approval/request 对"注册在提问 agent scope 上"的监听器可达，claim / next() 语义与之一致。改动最小：插件想接就 claim，不想接就 delegate。
2. 显式的"注册审批 answerer"接口：公开注册一个 answerer，它返回 outcome，由宿主在多个已注册 answerer 之间仲裁（先答者胜）。这是与"多 surface 并存（桌面 + 手机 + …）"最契合的形态，也正是我们在宿主之外验证过的行为。
3. 若两者都不打算做：请把限制写进文档。 在 approval 相关包的 README 里加一句"审批仅由宿主自带 surface 参与"，至少能让插件作者不必再自己撞一遍这堵墙。那样我们会按"有意设计"撤回这个提案。

落地后会做什么

@aiwayds/dsh-feishu（社区插件，用飞书/Lark 驱动 dsh 会话）会补上手机端审批卡。它的用户已经在手机上作答问询卡、steer 回合，唯一缺的就是审批。我们已经验证过期望的最终行为（两端同时在线、先答者胜、落败的一方被替换成胜者的真实结果、终态卡仍保留工具/理由上下文），插件作者也表示宿主 seam 一落地他就在插件里实现手机审批卡 —— 见 fan56/dsh-feishu#5 的评论。

补充说明

• 我们不建议把原型里的传输层塞进插件：它依赖未文档化的内部实现，而且插件一旦自行派生浏览器会话凭据，就等于可以完整冒充 Web 客户端。把语义留在宿主这一侧受控，正是我们到这里来提需求、而不是自己绕过它的原因。
• 如果需要，我们可以提供：注册方式矩阵、trace 片段、以及原型的行为规格（竞速 / 退休 / 终态卡规则），方便评估改动量。

感谢阅读 —— 也感谢"一切皆插件"的设计；这是我们在它边界上撞到的那一处。

[argszero]

Thanks for the very concrete report — the "phone can answer questions but never approvals" framing is exactly the right way to state it. I spent a round reading the current tree (master @ d743267388) and reproducing the dispatch in a standalone harness. Three findings that change the shape of the request, then one about what is achievable today.

1. How the approval waterfall is actually keyed

ApprovalService.decide() (packages/interaction/user-approval/src/index.ts:267-290) dispatches:

this.ctx.waterfall(
  scopeTarget(req.agent, req.agent), 'approval/request', req,
  () => Promise.resolve<ApprovalOutcome>('unavailable'),
)

So the dispatch key is the asking agent's scope, not the service owner's and not the requester's. The admission rule is then in scopeTarget (packages/core/scope/src/index.ts:170-186): a listener whose own ctx carries no scope tag is admitted globally; a listener whose ctx carries a tag is admitted only when that tag is the key itself or an ancestor of it. A tag below the key stays excluded by design — the docstring puts it as "events flow up the chain, never down". A skipped listener produces no error and no log line, so "it never fired" and "it was filtered out" look identical from the outside.

One more fact that matters for your option 2, and for #5236: the 'never' policy is decided in-service, before any dispatch (index.ts:270-275, with an explicit comment saying a listener-shaped gate could not keep that promise). So no listener can ever gate the ask; the service is already the "first participant".

2. "My listener never fires" has three distinct causes — please don't stop at the first

(a) Filtered by scope. Your ctx is tagged below the asking agent (a preset child, a per-agent binding). Fix: register where the ctx is untagged or encloses the agents — ctx.root.on('approval/request', handler).

(b) Admitted, but never reached. waterfall runs listeners outermost-first, and a listener that returns without calling next() vetoes the rest of the chain (vendor/cordis/src/events.ts:234-243). The web profile's own answerer is the forwarded-browser listener registered by @deepseek-ai/dsh-api-remotes (packages/api/remotes/src/index.ts:51-70) — without prepend — and it awaits the browser and returns an outcome. Every listener registered after it is therefore dead code even though it is admitted. { prepend: true } is an unshift (events.ts:255), and it is the only way to sit ahead of it.

(c) A different process/plane. This is the one I'd check first on your machine. In 0.2 a session can run in a runtime carrier, and a listener in the shell process simply cannot see that waterfall; symmetrically, the web browser half is a separate process that receives host events through ctx.remote.$on(...) (packages/client/ui-approval/src/client/index.ts:104), where ctx.on(...) is a no-op by construction.

A one-line way to tell them apart in your own plugin: register a control listener on an event that provably fires in the same ctx (agent/created is a good one) next to your approval listener. Control fires + approval does not ⇒ (a) or (c). Neither fires ⇒ (c).

I want to be explicit about what this evidence does not say: in a standalone cordis harness I measured an unscoped plugin ctx and { global: true } both receiving hits for an agent-keyed approval dispatch, so (a) alone does not explain your "never fired in five variants". That asymmetry is why (c) is worth an explicit measurement rather than an assumption — and it is also the honest limit of my analysis: I cannot reproduce your Electron/desktop layout from here.

3. What you're asking for is achievable without a core change

Your option 2 — an explicit answerer registry with first-answer-wins — does not need a new core API to exist, because approval/request is already a documented waterfall whose contract is "return an outcome to claim the request or call next() to delegate" (packages/interaction/user-approval/src/types.ts:83-95). A plugin can:

• install one { prepend: true } listener, so it is outer to the browser forwarder, and
• expose register(answerer) to every other plugin, then race the registered answerers against the host chain (next()), first vocabulary outcome wins, the loser's late answer discarded.

That gives exactly the semantics you validated in your prototype: both surfaces are presented, the first answer wins, and the tool call receives the winner's real outcome.

Two properties I would hold such a plugin to, both testable: with zero answerers registered it must be byte-identical to next() (no behaviour change for anyone not using it), and a bridged request can never wait longer than the host chain alone — the race settles at the minimum over its participants, so the surface with no UI can only ever shorten the wait, never lengthen it.

I am building this as @argszero/dsh-approval-bridge and will post the npm + repo link in this thread when it is out, so @aiwayds/dsh-feishu and any other surface can ship phone approvals without waiting for the core seam. Honest boundary, stated up front: it is a runtime-plane seam, not the core one you proposed — the ask still originates in the service, so the bridge must be present in the process where the sessions run; and it cannot un-draw a card another surface has already displayed (retiring the loser's UI is the surface's business). Your options 1 and 2 remain the durable fixes; this only makes the capability available until then.

If you can paste the registration matrix (which ctx each of the five variants was registered on) and whether your control event fired, I can name which of (a)/(b)/(c) it is in one pass — and if it turns out to be (c), that is a finding worth its own thread, because it would mean profile plugins and the runtime carrier disagree about which process owns the approval chain.

[argszero]

The gap this thread describes now has a plugin form, so a third-party surface does not have to be written against the seam from scratch.

@argszero/dsh-approval-bridge 0.1.0

• npm: https://www.npmjs.com/package/@argszero/dsh-approval-bridge
• source (MIT): https://github.com/argszero/dsh-approval-bridge

npm install @argszero/dsh-approval-bridge

Mount it at the profile (root) level, then a surface plugin registers an answerer — that is the whole integration:

ctx.inject(['approvalBridge'], (scoped) => {
  scoped.effect(() => scoped.approvalBridge.register({
    name: 'phone',
    match: ask => ask.toolName === 'bash',
    answer: async ask => (await promptOnThePhone(ask)) ?? undefined,
  }))
})

A claiming outcome ('allowed-once' / 'rejected' / 'cancelled') decides the request; undefined / null / 'unavailable' abstains and leaves it to the other answerers and the host chain. The first claimant wins, abstentions do not end the exchange, and a throwing answerer is contained as an abstention — no answerer's bug can fail an approval open.

The seam, measured rather than read. npm run probe:seam registers exactly these listeners against the published packages:

arm	result
untagged + {prepend: true}	fired=1 outcome=unavailable
forwarder registered first, bridge with prepend	order ["bridge","forwarder"]
the same listener without prepend	order ["forwarder"] — the bridge is never reached
listener on the asking agent's own scope	fired=1
listener on a sibling agent's scope	fired=0, and nothing is logged
isScopeCarrier(scopeTarget(a,a)) / scopeOf(root)	true / undefined

The second-to-last row is the one worth repeating: a scope-tagged listener is skipped silently, which is why the plugin's untagged test is written against scopeOf and not against the carrier.

The report answers the question the harness does not. approval_bridge_report prints the dispatch counter — the denominator that separates "my listener is not admitted" from "no approval was ever requested" — together with the scope posture, the per-answerer counters (calls / claims / abstains / errors) and the retained request tail. mode: observe runs the whole measurement while deciding nothing, which is how a deployment can be checked before the bridge is trusted.

Honest boundaries. It cannot make a tagged listener admitted (that is the dispatcher's filter). Under the default race posture the host chain is entered immediately, so a deployment with two surfaces online at once may see the bridge win while the host's own card is still on screen — withdrawing it is that surface's business, not a runtime-plane plugin's; defer is the posture that never draws the host card, at the price of the answerer's own latency. It cannot override a session's 'never' policy: the approval service resolves that before dispatching, so such a session never reaches the listener in any mode.

Evidence: 41 test arms against a real cordis Context, the real ToolRuntime and a real waterfall; 24/24 mutation arms caught with none silent; every one of the 7 harness lines the peer range admits probed with the whole line pinned.