fix(runtime-host): restore desktop Computer Use capability by M4n5ter · Pull Request #2233 · apache/maka

M4n5ter · 2026-08-05T11:30:02Z

English

Summary

accept the real Desktop Computer Use tool schema in the Client Capability protocol
keep pre-dispatch rejections, including Client Capability boundary and subagent admission failures, on the generic call/response lane
request the native macOS Accessibility grant once, on the first explicit Computer Use attempt
cover the real Desktop offer, protocol boundary, durable rejection path, and native backend request

Root cause

Desktop only publishes its Computer Use offer when the native backend is available. Once a real maka-cu backend was present, its draft-07 tuple schemas and tool description exceeded assumptions in the Client Capability decoder, so registration failed and the Host exposed only the Agent and Browser groups.

A separate failure existed when a call was rejected before dispatch, including Client Capability boundary and saturated subagent admission failures: the call received a durable operation id before durable preparation. Its synthetic response then had no matching durable call, producing an orphan response and draining the Runtime Host.

Finally, the native protocol already supported an explicit Accessibility prompt, but Maka used only silent permission probes. The first explicit Computer Use attempt now requests that grant once while routine per-action preflight remains silent.

Validation

@maka/runtime: 3179 passed, 9 skipped
@maka/computer-use: 134 passed
@maka/runtime-host: 693 passed
@maka/desktop: 1738 passed
Runtime, Runtime Host, Computer Use, and Desktop type checks
Biome and git diff --check
real host-backed Desktop flow: discover the Desktop Computer Use group, load maka_computer, grant Accessibility, invoke list_apps, and receive the native app list

Follow-up

native Screen Recording consent is tracked in maka-cu#1

中文

概述

让 Client Capability 协议接受 Desktop Computer Use 的真实工具 schema
让 dispatch 前被拒绝的调用（包括 Client Capability 边界和 subagent admission 失败）继续使用普通 call/response lane
在首次明确使用 Computer Use 时，仅主动请求一次 macOS Accessibility 权限
覆盖真实 Desktop offer、协议边界、durable 拒绝路径与 native backend 授权请求

根因

Desktop 仅在 native backend 可用时发布 Computer Use offer。接入真实 maka-cu 后，其 draft-07 tuple schema 和工具描述超出了 Client Capability decoder 原有假设，导致注册失败，Host 最终只能暴露 Agent 和 Browser 两个工具组。

另一个问题出现在调用于 dispatch 前被拒绝时，包括 Client Capability 边界拒绝和 subagent admission 饱和：调用在 durable prepare 前已经获得 operation id，随后生成的 synthetic response 找不到对应 durable call，形成 orphan response 并使 Runtime Host 进入 draining。

此外，native 协议已经支持显式触发 Accessibility 授权，但 Maka 之前只执行静默检查。现在首次明确使用 Computer Use 时会请求一次授权，日常逐操作 preflight 仍保持静默。

验证

@maka/runtime：3179 passed，9 skipped
@maka/computer-use：134 passed
@maka/runtime-host：693 passed
@maka/desktop：1738 passed
Runtime、Runtime Host、Computer Use 与 Desktop typecheck
Biome 与 git diff --check
真实 host-backed Desktop 链路：发现 Desktop Computer Use 组、加载 maka_computer、完成 Accessibility 授权、调用 list_apps 并取得 native 应用列表

后续

native Screen Recording 主动授权由 maka-cu#1 跟踪

A pre-dispatch tool refusal used to kill the turn. The call event's lane was guessed when the event was built: an `operationId` claims the T1 dispatch protocol, so AgentRun skips the generic projection of that `function_call` and waits for `commitToolPrepared` — which sits after every refusal return. The call fact was never persisted, the synthetic result landed on the generic lane with nothing to attach to, and the ledger refused the `orphan_response` (apache#2234). apache#2233 closed that by predicting the refusals instead: every guard hoisted into a `preflightRejected` boolean read before the operationId. It is correct only while the prediction and the guards agree, and nothing holds them together — a new refusal path, or a guard that grows a condition its hoisted twin does not, silently restores the orphan. This decides the lane where it is known. `pushCallEvent('preflight'|'dispatch')` pushes at most once, every refusal routes through one `refuseBeforeDispatch` helper that keeps call and result together on the generic lane, and only `prepareDurableToolAttempt` asks for T1. The decision is the code path taken, so it cannot drift. apache#2233's predicate, its hoisted boundary read and its early slot reservation go with it; the boundary read and the reservation return to the guards they belong to, and everything else apache#2233 restored is untouched. Two things apache#2233 did not cover, both from the same failure: - A rejected append latched the RuntimeEvent store unavailable, and `commitTerminalRun` returns early on an unavailable store, so one refused event cost the run its own terminal write — a run stuck at `running` with no terminal event. `ToolLedgerRejectionError` now marks a refusal of one bad candidate against a healthy store, and only that skips the latch. An already corrupt ledger refuses well-formed writes for a different reason, so it throws `ToolLedgerCorruptionError` and keeps failing closed. - `agent_swarm`'s selector refusal said only "Provide exactly one of subagent_id or legacy profile", naming neither which of the two mistakes it was nor one value that would work — and the field list an args violation appends is the top-level one, not `items[n]` where the violation was. Tests: `pre-dispatch-refusal-ledger.test.ts` drives all seven refusal paths through the real `scanToolLedger`; on the tagged lane every one of them reproduces the production `orphan_response`. The terminal-write and ledger-corruption cases run against a `canonical` store, the only durability production ships. Refs apache#2234

A pre-dispatch tool refusal used to kill the turn. The call event's lane was guessed when the event was built: an `operationId` claims the T1 dispatch protocol, so AgentRun skips the generic projection of that `function_call` and waits for `commitToolPrepared` — which sits after every refusal return. The call fact was never persisted, the synthetic result landed on the generic lane with nothing to attach to, and the ledger refused the `orphan_response` (apache#2234). apache#2233 closed that by predicting the refusals instead: every guard hoisted into a `preflightRejected` boolean read before the operationId. It is correct only while the prediction and the guards agree, and nothing holds them together — a new refusal path, or a guard that grows a condition its hoisted twin does not, silently restores the orphan. This decides the lane where it is known. `pushCallEvent('preflight'|'dispatch')` pushes at most once, every refusal routes through one `refuseBeforeDispatch` helper that keeps call and result together on the generic lane, and only `prepareDurableToolAttempt` asks for T1. The decision is the code path taken, so it cannot drift. apache#2233's predicate, its hoisted boundary read and its early slot reservation go with it; the boundary read and the reservation return to the guards they belong to, and everything else apache#2233 restored is untouched. Two things apache#2233 did not cover, both from the same failure: - A rejected append latched the RuntimeEvent store unavailable, and `commitTerminalRun` returns early on an unavailable store, so one refused event cost the run its own terminal write — a run stuck at `running` with no terminal event. `ToolLedgerRejectionError` now marks a refusal of one bad candidate against a healthy store, and only that skips the latch. Damage found by the workspace health scan throws `ToolLedgerCorruptionError` and keeps failing closed. Be precise about what that second class buys, because the obvious rationale is wrong: the health scan runs only for tool-bearing events, so a damaged ledger refuses tool facts and would have taken the terminal event. The latch is what keeps it out, which reproduces apache#2234's shape for an already-damaged workspace. Left standing deliberately — it is a behaviour change on a path this commit does not otherwise touch — and tracked in apache#2313, with a test that pins the current price rather than hiding it. - `agent_swarm`'s selector refusal said only "Provide exactly one of subagent_id or legacy profile", naming neither which of the two mistakes it was nor one value that would work — and the field list an args violation appends is the top-level one, not `items[n]` where the violation was. Tests: `pre-dispatch-refusal-ledger.test.ts` drives all seven refusal paths through the real `scanToolLedger`; on the tagged lane every one of them reproduces the production `orphan_response`. The terminal-write and ledger-corruption cases run against a `canonical` store, the only durability production ships. Both error classes are pinned where they are produced, in `sqlite-runtime-store.test.ts`: their messages are byte-identical to the plain `Error` strings they replaced, so nothing else in that suite would notice a regression to `throw new Error(...)` — and the latch exemption would silently stop working. Refs apache#2234

…2240) A pre-dispatch tool refusal used to kill the turn. The call event's lane was guessed when the event was built: an `operationId` claims the T1 dispatch protocol, so AgentRun skips the generic projection of that `function_call` and waits for `commitToolPrepared` — which sits after every refusal return. The call fact was never persisted, the synthetic result landed on the generic lane with nothing to attach to, and the ledger refused the `orphan_response` (#2234). #2233 closed that by predicting the refusals instead: every guard hoisted into a `preflightRejected` boolean read before the operationId. It is correct only while the prediction and the guards agree, and nothing holds them together — a new refusal path, or a guard that grows a condition its hoisted twin does not, silently restores the orphan. This decides the lane where it is known. `pushCallEvent('preflight'|'dispatch')` pushes at most once, every refusal routes through one `refuseBeforeDispatch` helper that keeps call and result together on the generic lane, and only `prepareDurableToolAttempt` asks for T1. The decision is the code path taken, so it cannot drift. #2233's predicate, its hoisted boundary read and its early slot reservation go with it; the boundary read and the reservation return to the guards they belong to, and everything else #2233 restored is untouched. Two things #2233 did not cover, both from the same failure: - A rejected append latched the RuntimeEvent store unavailable, and `commitTerminalRun` returns early on an unavailable store, so one refused event cost the run its own terminal write — a run stuck at `running` with no terminal event. `ToolLedgerRejectionError` now marks a refusal of one bad candidate against a healthy store, and only that skips the latch. Damage found by the workspace health scan throws `ToolLedgerCorruptionError` and keeps failing closed. Be precise about what that second class buys, because the obvious rationale is wrong: the health scan runs only for tool-bearing events, so a damaged ledger refuses tool facts and would have taken the terminal event. The latch is what keeps it out, which reproduces #2234's shape for an already-damaged workspace. Left standing deliberately — it is a behaviour change on a path this commit does not otherwise touch — and tracked in #2313, with a test that pins the current price rather than hiding it. - `agent_swarm`'s selector refusal said only "Provide exactly one of subagent_id or legacy profile", naming neither which of the two mistakes it was nor one value that would work — and the field list an args violation appends is the top-level one, not `items[n]` where the violation was. Tests: `pre-dispatch-refusal-ledger.test.ts` drives all seven refusal paths through the real `scanToolLedger`; on the tagged lane every one of them reproduces the production `orphan_response`. The terminal-write and ledger-corruption cases run against a `canonical` store, the only durability production ships. Both error classes are pinned where they are produced, in `sqlite-runtime-store.test.ts`: their messages are byte-identical to the plain `Error` strings they replaced, so nothing else in that suite would notice a regression to `throw new Error(...)` — and the latch exemption would silently stop working. Refs #2234

M4n5ter · 2026-08-05T11:30:02Z

English

Summary

accept the real Desktop Computer Use tool schema in the Client Capability protocol
keep pre-dispatch rejections, including Client Capability boundary and subagent admission failures, on the generic call/response lane
request the native macOS Accessibility grant once, on the first explicit Computer Use attempt
cover the real Desktop offer, protocol boundary, durable rejection path, and native backend request

Root cause

Desktop only publishes its Computer Use offer when the native backend is available. Once a real maka-cu backend was present, its draft-07 tuple schemas and tool description exceeded assumptions in the Client Capability decoder, so registration failed and the Host exposed only the Agent and Browser groups.

A separate failure existed when a call was rejected before dispatch, including Client Capability boundary and saturated subagent admission failures: the call received a durable operation id before durable preparation. Its synthetic response then had no matching durable call, producing an orphan response and draining the Runtime Host.

Finally, the native protocol already supported an explicit Accessibility prompt, but Maka used only silent permission probes. The first explicit Computer Use attempt now requests that grant once while routine per-action preflight remains silent.

Validation

@maka/runtime: 3179 passed, 9 skipped
@maka/computer-use: 134 passed
@maka/runtime-host: 693 passed
@maka/desktop: 1738 passed
Runtime, Runtime Host, Computer Use, and Desktop type checks
Biome and git diff --check
real host-backed Desktop flow: discover the Desktop Computer Use group, load maka_computer, grant Accessibility, invoke list_apps, and receive the native app list

Follow-up

native Screen Recording consent is tracked in maka-cu#1

中文

概述

让 Client Capability 协议接受 Desktop Computer Use 的真实工具 schema
让 dispatch 前被拒绝的调用（包括 Client Capability 边界和 subagent admission 失败）继续使用普通 call/response lane
在首次明确使用 Computer Use 时，仅主动请求一次 macOS Accessibility 权限
覆盖真实 Desktop offer、协议边界、durable 拒绝路径与 native backend 授权请求

根因

Desktop 仅在 native backend 可用时发布 Computer Use offer。接入真实 maka-cu 后，其 draft-07 tuple schema 和工具描述超出了 Client Capability decoder 原有假设，导致注册失败，Host 最终只能暴露 Agent 和 Browser 两个工具组。

另一个问题出现在调用于 dispatch 前被拒绝时，包括 Client Capability 边界拒绝和 subagent admission 饱和：调用在 durable prepare 前已经获得 operation id，随后生成的 synthetic response 找不到对应 durable call，形成 orphan response 并使 Runtime Host 进入 draining。

此外，native 协议已经支持显式触发 Accessibility 授权，但 Maka 之前只执行静默检查。现在首次明确使用 Computer Use 时会请求一次授权，日常逐操作 preflight 仍保持静默。

验证

@maka/runtime：3179 passed，9 skipped
@maka/computer-use：134 passed
@maka/runtime-host：693 passed
@maka/desktop：1738 passed
Runtime、Runtime Host、Computer Use 与 Desktop typecheck
Biome 与 git diff --check
真实 host-backed Desktop 链路：发现 Desktop Computer Use 组、加载 maka_computer、完成 Accessibility 授权、调用 list_apps 并取得 native 应用列表

后续

native Screen Recording 主动授权由 maka-cu#1 跟踪

A pre-dispatch tool refusal used to kill the turn. The call event's lane was guessed when the event was built: an `operationId` claims the T1 dispatch protocol, so AgentRun skips the generic projection of that `function_call` and waits for `commitToolPrepared` — which sits after every refusal return. The call fact was never persisted, the synthetic result landed on the generic lane with nothing to attach to, and the ledger refused the `orphan_response` (apache#2234). apache#2233 closed that by predicting the refusals instead: every guard hoisted into a `preflightRejected` boolean read before the operationId. It is correct only while the prediction and the guards agree, and nothing holds them together — a new refusal path, or a guard that grows a condition its hoisted twin does not, silently restores the orphan. This decides the lane where it is known. `pushCallEvent('preflight'|'dispatch')` pushes at most once, every refusal routes through one `refuseBeforeDispatch` helper that keeps call and result together on the generic lane, and only `prepareDurableToolAttempt` asks for T1. The decision is the code path taken, so it cannot drift. apache#2233's predicate, its hoisted boundary read and its early slot reservation go with it; the boundary read and the reservation return to the guards they belong to, and everything else apache#2233 restored is untouched. Two things apache#2233 did not cover, both from the same failure: - A rejected append latched the RuntimeEvent store unavailable, and `commitTerminalRun` returns early on an unavailable store, so one refused event cost the run its own terminal write — a run stuck at `running` with no terminal event. `ToolLedgerRejectionError` now marks a refusal of one bad candidate against a healthy store, and only that skips the latch. An already corrupt ledger refuses well-formed writes for a different reason, so it throws `ToolLedgerCorruptionError` and keeps failing closed. - `agent_swarm`'s selector refusal said only "Provide exactly one of subagent_id or legacy profile", naming neither which of the two mistakes it was nor one value that would work — and the field list an args violation appends is the top-level one, not `items[n]` where the violation was. Tests: `pre-dispatch-refusal-ledger.test.ts` drives all seven refusal paths through the real `scanToolLedger`; on the tagged lane every one of them reproduces the production `orphan_response`. The terminal-write and ledger-corruption cases run against a `canonical` store, the only durability production ships. Refs apache#2234

A pre-dispatch tool refusal used to kill the turn. The call event's lane was guessed when the event was built: an `operationId` claims the T1 dispatch protocol, so AgentRun skips the generic projection of that `function_call` and waits for `commitToolPrepared` — which sits after every refusal return. The call fact was never persisted, the synthetic result landed on the generic lane with nothing to attach to, and the ledger refused the `orphan_response` (apache#2234). apache#2233 closed that by predicting the refusals instead: every guard hoisted into a `preflightRejected` boolean read before the operationId. It is correct only while the prediction and the guards agree, and nothing holds them together — a new refusal path, or a guard that grows a condition its hoisted twin does not, silently restores the orphan. This decides the lane where it is known. `pushCallEvent('preflight'|'dispatch')` pushes at most once, every refusal routes through one `refuseBeforeDispatch` helper that keeps call and result together on the generic lane, and only `prepareDurableToolAttempt` asks for T1. The decision is the code path taken, so it cannot drift. apache#2233's predicate, its hoisted boundary read and its early slot reservation go with it; the boundary read and the reservation return to the guards they belong to, and everything else apache#2233 restored is untouched. Two things apache#2233 did not cover, both from the same failure: - A rejected append latched the RuntimeEvent store unavailable, and `commitTerminalRun` returns early on an unavailable store, so one refused event cost the run its own terminal write — a run stuck at `running` with no terminal event. `ToolLedgerRejectionError` now marks a refusal of one bad candidate against a healthy store, and only that skips the latch. Damage found by the workspace health scan throws `ToolLedgerCorruptionError` and keeps failing closed. Be precise about what that second class buys, because the obvious rationale is wrong: the health scan runs only for tool-bearing events, so a damaged ledger refuses tool facts and would have taken the terminal event. The latch is what keeps it out, which reproduces apache#2234's shape for an already-damaged workspace. Left standing deliberately — it is a behaviour change on a path this commit does not otherwise touch — and tracked in apache#2313, with a test that pins the current price rather than hiding it. - `agent_swarm`'s selector refusal said only "Provide exactly one of subagent_id or legacy profile", naming neither which of the two mistakes it was nor one value that would work — and the field list an args violation appends is the top-level one, not `items[n]` where the violation was. Tests: `pre-dispatch-refusal-ledger.test.ts` drives all seven refusal paths through the real `scanToolLedger`; on the tagged lane every one of them reproduces the production `orphan_response`. The terminal-write and ledger-corruption cases run against a `canonical` store, the only durability production ships. Both error classes are pinned where they are produced, in `sqlite-runtime-store.test.ts`: their messages are byte-identical to the plain `Error` strings they replaced, so nothing else in that suite would notice a regression to `throw new Error(...)` — and the latch exemption would silently stop working. Refs apache#2234

…2240) A pre-dispatch tool refusal used to kill the turn. The call event's lane was guessed when the event was built: an `operationId` claims the T1 dispatch protocol, so AgentRun skips the generic projection of that `function_call` and waits for `commitToolPrepared` — which sits after every refusal return. The call fact was never persisted, the synthetic result landed on the generic lane with nothing to attach to, and the ledger refused the `orphan_response` (#2234). #2233 closed that by predicting the refusals instead: every guard hoisted into a `preflightRejected` boolean read before the operationId. It is correct only while the prediction and the guards agree, and nothing holds them together — a new refusal path, or a guard that grows a condition its hoisted twin does not, silently restores the orphan. This decides the lane where it is known. `pushCallEvent('preflight'|'dispatch')` pushes at most once, every refusal routes through one `refuseBeforeDispatch` helper that keeps call and result together on the generic lane, and only `prepareDurableToolAttempt` asks for T1. The decision is the code path taken, so it cannot drift. #2233's predicate, its hoisted boundary read and its early slot reservation go with it; the boundary read and the reservation return to the guards they belong to, and everything else #2233 restored is untouched. Two things #2233 did not cover, both from the same failure: - A rejected append latched the RuntimeEvent store unavailable, and `commitTerminalRun` returns early on an unavailable store, so one refused event cost the run its own terminal write — a run stuck at `running` with no terminal event. `ToolLedgerRejectionError` now marks a refusal of one bad candidate against a healthy store, and only that skips the latch. Damage found by the workspace health scan throws `ToolLedgerCorruptionError` and keeps failing closed. Be precise about what that second class buys, because the obvious rationale is wrong: the health scan runs only for tool-bearing events, so a damaged ledger refuses tool facts and would have taken the terminal event. The latch is what keeps it out, which reproduces #2234's shape for an already-damaged workspace. Left standing deliberately — it is a behaviour change on a path this commit does not otherwise touch — and tracked in #2313, with a test that pins the current price rather than hiding it. - `agent_swarm`'s selector refusal said only "Provide exactly one of subagent_id or legacy profile", naming neither which of the two mistakes it was nor one value that would work — and the field list an args violation appends is the top-level one, not `items[n]` where the violation was. Tests: `pre-dispatch-refusal-ledger.test.ts` drives all seven refusal paths through the real `scanToolLedger`; on the tagged lane every one of them reproduces the production `orphan_response`. The terminal-write and ledger-corruption cases run against a `canonical` store, the only durability production ships. Both error classes are pinned where they are produced, in `sqlite-runtime-store.test.ts`: their messages are byte-identical to the plain `Error` strings they replaced, so nothing else in that suite would notice a regression to `throw new Error(...)` — and the latch exemption would silently stop working. Refs #2234

M4n5ter · 2026-08-05T11:30:02Z

English

Summary

accept the real Desktop Computer Use tool schema in the Client Capability protocol
keep pre-dispatch rejections, including Client Capability boundary and subagent admission failures, on the generic call/response lane
request the native macOS Accessibility grant once, on the first explicit Computer Use attempt
cover the real Desktop offer, protocol boundary, durable rejection path, and native backend request

Root cause

Desktop only publishes its Computer Use offer when the native backend is available. Once a real maka-cu backend was present, its draft-07 tuple schemas and tool description exceeded assumptions in the Client Capability decoder, so registration failed and the Host exposed only the Agent and Browser groups.

A separate failure existed when a call was rejected before dispatch, including Client Capability boundary and saturated subagent admission failures: the call received a durable operation id before durable preparation. Its synthetic response then had no matching durable call, producing an orphan response and draining the Runtime Host.

Finally, the native protocol already supported an explicit Accessibility prompt, but Maka used only silent permission probes. The first explicit Computer Use attempt now requests that grant once while routine per-action preflight remains silent.

Validation

@maka/runtime: 3179 passed, 9 skipped
@maka/computer-use: 134 passed
@maka/runtime-host: 693 passed
@maka/desktop: 1738 passed
Runtime, Runtime Host, Computer Use, and Desktop type checks
Biome and git diff --check
real host-backed Desktop flow: discover the Desktop Computer Use group, load maka_computer, grant Accessibility, invoke list_apps, and receive the native app list

Follow-up

native Screen Recording consent is tracked in maka-cu#1

中文

概述

让 Client Capability 协议接受 Desktop Computer Use 的真实工具 schema
让 dispatch 前被拒绝的调用（包括 Client Capability 边界和 subagent admission 失败）继续使用普通 call/response lane
在首次明确使用 Computer Use 时，仅主动请求一次 macOS Accessibility 权限
覆盖真实 Desktop offer、协议边界、durable 拒绝路径与 native backend 授权请求

根因

Desktop 仅在 native backend 可用时发布 Computer Use offer。接入真实 maka-cu 后，其 draft-07 tuple schema 和工具描述超出了 Client Capability decoder 原有假设，导致注册失败，Host 最终只能暴露 Agent 和 Browser 两个工具组。

另一个问题出现在调用于 dispatch 前被拒绝时，包括 Client Capability 边界拒绝和 subagent admission 饱和：调用在 durable prepare 前已经获得 operation id，随后生成的 synthetic response 找不到对应 durable call，形成 orphan response 并使 Runtime Host 进入 draining。

此外，native 协议已经支持显式触发 Accessibility 授权，但 Maka 之前只执行静默检查。现在首次明确使用 Computer Use 时会请求一次授权，日常逐操作 preflight 仍保持静默。

验证

@maka/runtime：3179 passed，9 skipped
@maka/computer-use：134 passed
@maka/runtime-host：693 passed
@maka/desktop：1738 passed
Runtime、Runtime Host、Computer Use 与 Desktop typecheck
Biome 与 git diff --check
真实 host-backed Desktop 链路：发现 Desktop Computer Use 组、加载 maka_computer、完成 Accessibility 授权、调用 list_apps 并取得 native 应用列表

后续

native Screen Recording 主动授权由 maka-cu#1 跟踪

A pre-dispatch tool refusal used to kill the turn. The call event's lane was guessed when the event was built: an `operationId` claims the T1 dispatch protocol, so AgentRun skips the generic projection of that `function_call` and waits for `commitToolPrepared` — which sits after every refusal return. The call fact was never persisted, the synthetic result landed on the generic lane with nothing to attach to, and the ledger refused the `orphan_response` (apache#2234). apache#2233 closed that by predicting the refusals instead: every guard hoisted into a `preflightRejected` boolean read before the operationId. It is correct only while the prediction and the guards agree, and nothing holds them together — a new refusal path, or a guard that grows a condition its hoisted twin does not, silently restores the orphan. This decides the lane where it is known. `pushCallEvent('preflight'|'dispatch')` pushes at most once, every refusal routes through one `refuseBeforeDispatch` helper that keeps call and result together on the generic lane, and only `prepareDurableToolAttempt` asks for T1. The decision is the code path taken, so it cannot drift. apache#2233's predicate, its hoisted boundary read and its early slot reservation go with it; the boundary read and the reservation return to the guards they belong to, and everything else apache#2233 restored is untouched. Two things apache#2233 did not cover, both from the same failure: - A rejected append latched the RuntimeEvent store unavailable, and `commitTerminalRun` returns early on an unavailable store, so one refused event cost the run its own terminal write — a run stuck at `running` with no terminal event. `ToolLedgerRejectionError` now marks a refusal of one bad candidate against a healthy store, and only that skips the latch. An already corrupt ledger refuses well-formed writes for a different reason, so it throws `ToolLedgerCorruptionError` and keeps failing closed. - `agent_swarm`'s selector refusal said only "Provide exactly one of subagent_id or legacy profile", naming neither which of the two mistakes it was nor one value that would work — and the field list an args violation appends is the top-level one, not `items[n]` where the violation was. Tests: `pre-dispatch-refusal-ledger.test.ts` drives all seven refusal paths through the real `scanToolLedger`; on the tagged lane every one of them reproduces the production `orphan_response`. The terminal-write and ledger-corruption cases run against a `canonical` store, the only durability production ships. Refs apache#2234

A pre-dispatch tool refusal used to kill the turn. The call event's lane was guessed when the event was built: an `operationId` claims the T1 dispatch protocol, so AgentRun skips the generic projection of that `function_call` and waits for `commitToolPrepared` — which sits after every refusal return. The call fact was never persisted, the synthetic result landed on the generic lane with nothing to attach to, and the ledger refused the `orphan_response` (apache#2234). apache#2233 closed that by predicting the refusals instead: every guard hoisted into a `preflightRejected` boolean read before the operationId. It is correct only while the prediction and the guards agree, and nothing holds them together — a new refusal path, or a guard that grows a condition its hoisted twin does not, silently restores the orphan. This decides the lane where it is known. `pushCallEvent('preflight'|'dispatch')` pushes at most once, every refusal routes through one `refuseBeforeDispatch` helper that keeps call and result together on the generic lane, and only `prepareDurableToolAttempt` asks for T1. The decision is the code path taken, so it cannot drift. apache#2233's predicate, its hoisted boundary read and its early slot reservation go with it; the boundary read and the reservation return to the guards they belong to, and everything else apache#2233 restored is untouched. Two things apache#2233 did not cover, both from the same failure: - A rejected append latched the RuntimeEvent store unavailable, and `commitTerminalRun` returns early on an unavailable store, so one refused event cost the run its own terminal write — a run stuck at `running` with no terminal event. `ToolLedgerRejectionError` now marks a refusal of one bad candidate against a healthy store, and only that skips the latch. Damage found by the workspace health scan throws `ToolLedgerCorruptionError` and keeps failing closed. Be precise about what that second class buys, because the obvious rationale is wrong: the health scan runs only for tool-bearing events, so a damaged ledger refuses tool facts and would have taken the terminal event. The latch is what keeps it out, which reproduces apache#2234's shape for an already-damaged workspace. Left standing deliberately — it is a behaviour change on a path this commit does not otherwise touch — and tracked in apache#2313, with a test that pins the current price rather than hiding it. - `agent_swarm`'s selector refusal said only "Provide exactly one of subagent_id or legacy profile", naming neither which of the two mistakes it was nor one value that would work — and the field list an args violation appends is the top-level one, not `items[n]` where the violation was. Tests: `pre-dispatch-refusal-ledger.test.ts` drives all seven refusal paths through the real `scanToolLedger`; on the tagged lane every one of them reproduces the production `orphan_response`. The terminal-write and ledger-corruption cases run against a `canonical` store, the only durability production ships. Both error classes are pinned where they are produced, in `sqlite-runtime-store.test.ts`: their messages are byte-identical to the plain `Error` strings they replaced, so nothing else in that suite would notice a regression to `throw new Error(...)` — and the latch exemption would silently stop working. Refs apache#2234

…2240) A pre-dispatch tool refusal used to kill the turn. The call event's lane was guessed when the event was built: an `operationId` claims the T1 dispatch protocol, so AgentRun skips the generic projection of that `function_call` and waits for `commitToolPrepared` — which sits after every refusal return. The call fact was never persisted, the synthetic result landed on the generic lane with nothing to attach to, and the ledger refused the `orphan_response` (#2234). #2233 closed that by predicting the refusals instead: every guard hoisted into a `preflightRejected` boolean read before the operationId. It is correct only while the prediction and the guards agree, and nothing holds them together — a new refusal path, or a guard that grows a condition its hoisted twin does not, silently restores the orphan. This decides the lane where it is known. `pushCallEvent('preflight'|'dispatch')` pushes at most once, every refusal routes through one `refuseBeforeDispatch` helper that keeps call and result together on the generic lane, and only `prepareDurableToolAttempt` asks for T1. The decision is the code path taken, so it cannot drift. #2233's predicate, its hoisted boundary read and its early slot reservation go with it; the boundary read and the reservation return to the guards they belong to, and everything else #2233 restored is untouched. Two things #2233 did not cover, both from the same failure: - A rejected append latched the RuntimeEvent store unavailable, and `commitTerminalRun` returns early on an unavailable store, so one refused event cost the run its own terminal write — a run stuck at `running` with no terminal event. `ToolLedgerRejectionError` now marks a refusal of one bad candidate against a healthy store, and only that skips the latch. Damage found by the workspace health scan throws `ToolLedgerCorruptionError` and keeps failing closed. Be precise about what that second class buys, because the obvious rationale is wrong: the health scan runs only for tool-bearing events, so a damaged ledger refuses tool facts and would have taken the terminal event. The latch is what keeps it out, which reproduces #2234's shape for an already-damaged workspace. Left standing deliberately — it is a behaviour change on a path this commit does not otherwise touch — and tracked in #2313, with a test that pins the current price rather than hiding it. - `agent_swarm`'s selector refusal said only "Provide exactly one of subagent_id or legacy profile", naming neither which of the two mistakes it was nor one value that would work — and the field list an args violation appends is the top-level one, not `items[n]` where the violation was. Tests: `pre-dispatch-refusal-ledger.test.ts` drives all seven refusal paths through the real `scanToolLedger`; on the tagged lane every one of them reproduces the production `orphan_response`. The terminal-write and ledger-corruption cases run against a `canonical` store, the only durability production ships. Both error classes are pinned where they are produced, in `sqlite-runtime-store.test.ts`: their messages are byte-identical to the plain `Error` strings they replaced, so nothing else in that suite would notice a regression to `throw new Error(...)` — and the latch exemption would silently stop working. Refs #2234

M4n5ter · 2026-08-05T11:30:02Z

English

Summary

accept the real Desktop Computer Use tool schema in the Client Capability protocol
keep pre-dispatch rejections, including Client Capability boundary and subagent admission failures, on the generic call/response lane
request the native macOS Accessibility grant once, on the first explicit Computer Use attempt
cover the real Desktop offer, protocol boundary, durable rejection path, and native backend request

Root cause

Desktop only publishes its Computer Use offer when the native backend is available. Once a real maka-cu backend was present, its draft-07 tuple schemas and tool description exceeded assumptions in the Client Capability decoder, so registration failed and the Host exposed only the Agent and Browser groups.

A separate failure existed when a call was rejected before dispatch, including Client Capability boundary and saturated subagent admission failures: the call received a durable operation id before durable preparation. Its synthetic response then had no matching durable call, producing an orphan response and draining the Runtime Host.

Finally, the native protocol already supported an explicit Accessibility prompt, but Maka used only silent permission probes. The first explicit Computer Use attempt now requests that grant once while routine per-action preflight remains silent.

Validation

@maka/runtime: 3179 passed, 9 skipped
@maka/computer-use: 134 passed
@maka/runtime-host: 693 passed
@maka/desktop: 1738 passed
Runtime, Runtime Host, Computer Use, and Desktop type checks
Biome and git diff --check
real host-backed Desktop flow: discover the Desktop Computer Use group, load maka_computer, grant Accessibility, invoke list_apps, and receive the native app list

Follow-up

native Screen Recording consent is tracked in maka-cu#1

中文

概述

让 Client Capability 协议接受 Desktop Computer Use 的真实工具 schema
让 dispatch 前被拒绝的调用（包括 Client Capability 边界和 subagent admission 失败）继续使用普通 call/response lane
在首次明确使用 Computer Use 时，仅主动请求一次 macOS Accessibility 权限
覆盖真实 Desktop offer、协议边界、durable 拒绝路径与 native backend 授权请求

根因

Desktop 仅在 native backend 可用时发布 Computer Use offer。接入真实 maka-cu 后，其 draft-07 tuple schema 和工具描述超出了 Client Capability decoder 原有假设，导致注册失败，Host 最终只能暴露 Agent 和 Browser 两个工具组。

另一个问题出现在调用于 dispatch 前被拒绝时，包括 Client Capability 边界拒绝和 subagent admission 饱和：调用在 durable prepare 前已经获得 operation id，随后生成的 synthetic response 找不到对应 durable call，形成 orphan response 并使 Runtime Host 进入 draining。

此外，native 协议已经支持显式触发 Accessibility 授权，但 Maka 之前只执行静默检查。现在首次明确使用 Computer Use 时会请求一次授权，日常逐操作 preflight 仍保持静默。

验证

@maka/runtime：3179 passed，9 skipped
@maka/computer-use：134 passed
@maka/runtime-host：693 passed
@maka/desktop：1738 passed
Runtime、Runtime Host、Computer Use 与 Desktop typecheck
Biome 与 git diff --check
真实 host-backed Desktop 链路：发现 Desktop Computer Use 组、加载 maka_computer、完成 Accessibility 授权、调用 list_apps 并取得 native 应用列表

后续

native Screen Recording 主动授权由 maka-cu#1 跟踪

A pre-dispatch tool refusal used to kill the turn. The call event's lane was guessed when the event was built: an `operationId` claims the T1 dispatch protocol, so AgentRun skips the generic projection of that `function_call` and waits for `commitToolPrepared` — which sits after every refusal return. The call fact was never persisted, the synthetic result landed on the generic lane with nothing to attach to, and the ledger refused the `orphan_response` (apache#2234). apache#2233 closed that by predicting the refusals instead: every guard hoisted into a `preflightRejected` boolean read before the operationId. It is correct only while the prediction and the guards agree, and nothing holds them together — a new refusal path, or a guard that grows a condition its hoisted twin does not, silently restores the orphan. This decides the lane where it is known. `pushCallEvent('preflight'|'dispatch')` pushes at most once, every refusal routes through one `refuseBeforeDispatch` helper that keeps call and result together on the generic lane, and only `prepareDurableToolAttempt` asks for T1. The decision is the code path taken, so it cannot drift. apache#2233's predicate, its hoisted boundary read and its early slot reservation go with it; the boundary read and the reservation return to the guards they belong to, and everything else apache#2233 restored is untouched. Two things apache#2233 did not cover, both from the same failure: - A rejected append latched the RuntimeEvent store unavailable, and `commitTerminalRun` returns early on an unavailable store, so one refused event cost the run its own terminal write — a run stuck at `running` with no terminal event. `ToolLedgerRejectionError` now marks a refusal of one bad candidate against a healthy store, and only that skips the latch. An already corrupt ledger refuses well-formed writes for a different reason, so it throws `ToolLedgerCorruptionError` and keeps failing closed. - `agent_swarm`'s selector refusal said only "Provide exactly one of subagent_id or legacy profile", naming neither which of the two mistakes it was nor one value that would work — and the field list an args violation appends is the top-level one, not `items[n]` where the violation was. Tests: `pre-dispatch-refusal-ledger.test.ts` drives all seven refusal paths through the real `scanToolLedger`; on the tagged lane every one of them reproduces the production `orphan_response`. The terminal-write and ledger-corruption cases run against a `canonical` store, the only durability production ships. Refs apache#2234

A pre-dispatch tool refusal used to kill the turn. The call event's lane was guessed when the event was built: an `operationId` claims the T1 dispatch protocol, so AgentRun skips the generic projection of that `function_call` and waits for `commitToolPrepared` — which sits after every refusal return. The call fact was never persisted, the synthetic result landed on the generic lane with nothing to attach to, and the ledger refused the `orphan_response` (apache#2234). apache#2233 closed that by predicting the refusals instead: every guard hoisted into a `preflightRejected` boolean read before the operationId. It is correct only while the prediction and the guards agree, and nothing holds them together — a new refusal path, or a guard that grows a condition its hoisted twin does not, silently restores the orphan. This decides the lane where it is known. `pushCallEvent('preflight'|'dispatch')` pushes at most once, every refusal routes through one `refuseBeforeDispatch` helper that keeps call and result together on the generic lane, and only `prepareDurableToolAttempt` asks for T1. The decision is the code path taken, so it cannot drift. apache#2233's predicate, its hoisted boundary read and its early slot reservation go with it; the boundary read and the reservation return to the guards they belong to, and everything else apache#2233 restored is untouched. Two things apache#2233 did not cover, both from the same failure: - A rejected append latched the RuntimeEvent store unavailable, and `commitTerminalRun` returns early on an unavailable store, so one refused event cost the run its own terminal write — a run stuck at `running` with no terminal event. `ToolLedgerRejectionError` now marks a refusal of one bad candidate against a healthy store, and only that skips the latch. Damage found by the workspace health scan throws `ToolLedgerCorruptionError` and keeps failing closed. Be precise about what that second class buys, because the obvious rationale is wrong: the health scan runs only for tool-bearing events, so a damaged ledger refuses tool facts and would have taken the terminal event. The latch is what keeps it out, which reproduces apache#2234's shape for an already-damaged workspace. Left standing deliberately — it is a behaviour change on a path this commit does not otherwise touch — and tracked in apache#2313, with a test that pins the current price rather than hiding it. - `agent_swarm`'s selector refusal said only "Provide exactly one of subagent_id or legacy profile", naming neither which of the two mistakes it was nor one value that would work — and the field list an args violation appends is the top-level one, not `items[n]` where the violation was. Tests: `pre-dispatch-refusal-ledger.test.ts` drives all seven refusal paths through the real `scanToolLedger`; on the tagged lane every one of them reproduces the production `orphan_response`. The terminal-write and ledger-corruption cases run against a `canonical` store, the only durability production ships. Both error classes are pinned where they are produced, in `sqlite-runtime-store.test.ts`: their messages are byte-identical to the plain `Error` strings they replaced, so nothing else in that suite would notice a regression to `throw new Error(...)` — and the latch exemption would silently stop working. Refs apache#2234

…2240) A pre-dispatch tool refusal used to kill the turn. The call event's lane was guessed when the event was built: an `operationId` claims the T1 dispatch protocol, so AgentRun skips the generic projection of that `function_call` and waits for `commitToolPrepared` — which sits after every refusal return. The call fact was never persisted, the synthetic result landed on the generic lane with nothing to attach to, and the ledger refused the `orphan_response` (#2234). #2233 closed that by predicting the refusals instead: every guard hoisted into a `preflightRejected` boolean read before the operationId. It is correct only while the prediction and the guards agree, and nothing holds them together — a new refusal path, or a guard that grows a condition its hoisted twin does not, silently restores the orphan. This decides the lane where it is known. `pushCallEvent('preflight'|'dispatch')` pushes at most once, every refusal routes through one `refuseBeforeDispatch` helper that keeps call and result together on the generic lane, and only `prepareDurableToolAttempt` asks for T1. The decision is the code path taken, so it cannot drift. #2233's predicate, its hoisted boundary read and its early slot reservation go with it; the boundary read and the reservation return to the guards they belong to, and everything else #2233 restored is untouched. Two things #2233 did not cover, both from the same failure: - A rejected append latched the RuntimeEvent store unavailable, and `commitTerminalRun` returns early on an unavailable store, so one refused event cost the run its own terminal write — a run stuck at `running` with no terminal event. `ToolLedgerRejectionError` now marks a refusal of one bad candidate against a healthy store, and only that skips the latch. Damage found by the workspace health scan throws `ToolLedgerCorruptionError` and keeps failing closed. Be precise about what that second class buys, because the obvious rationale is wrong: the health scan runs only for tool-bearing events, so a damaged ledger refuses tool facts and would have taken the terminal event. The latch is what keeps it out, which reproduces #2234's shape for an already-damaged workspace. Left standing deliberately — it is a behaviour change on a path this commit does not otherwise touch — and tracked in #2313, with a test that pins the current price rather than hiding it. - `agent_swarm`'s selector refusal said only "Provide exactly one of subagent_id or legacy profile", naming neither which of the two mistakes it was nor one value that would work — and the field list an args violation appends is the top-level one, not `items[n]` where the violation was. Tests: `pre-dispatch-refusal-ledger.test.ts` drives all seven refusal paths through the real `scanToolLedger`; on the tagged lane every one of them reproduces the production `orphan_response`. The terminal-write and ledger-corruption cases run against a `canonical` store, the only durability production ships. Both error classes are pinned where they are produced, in `sqlite-runtime-store.test.ts`: their messages are byte-identical to the plain `Error` strings they replaced, so nothing else in that suite would notice a regression to `throw new Error(...)` — and the latch exemption would silently stop working. Refs #2234

M4n5ter · 2026-08-05T11:30:02Z

English

Summary

accept the real Desktop Computer Use tool schema in the Client Capability protocol
keep pre-dispatch rejections, including Client Capability boundary and subagent admission failures, on the generic call/response lane
request the native macOS Accessibility grant once, on the first explicit Computer Use attempt
cover the real Desktop offer, protocol boundary, durable rejection path, and native backend request

Root cause

Desktop only publishes its Computer Use offer when the native backend is available. Once a real maka-cu backend was present, its draft-07 tuple schemas and tool description exceeded assumptions in the Client Capability decoder, so registration failed and the Host exposed only the Agent and Browser groups.

A separate failure existed when a call was rejected before dispatch, including Client Capability boundary and saturated subagent admission failures: the call received a durable operation id before durable preparation. Its synthetic response then had no matching durable call, producing an orphan response and draining the Runtime Host.

Finally, the native protocol already supported an explicit Accessibility prompt, but Maka used only silent permission probes. The first explicit Computer Use attempt now requests that grant once while routine per-action preflight remains silent.

Validation

@maka/runtime: 3179 passed, 9 skipped
@maka/computer-use: 134 passed
@maka/runtime-host: 693 passed
@maka/desktop: 1738 passed
Runtime, Runtime Host, Computer Use, and Desktop type checks
Biome and git diff --check
real host-backed Desktop flow: discover the Desktop Computer Use group, load maka_computer, grant Accessibility, invoke list_apps, and receive the native app list

Follow-up

native Screen Recording consent is tracked in maka-cu#1

中文

概述

让 Client Capability 协议接受 Desktop Computer Use 的真实工具 schema
让 dispatch 前被拒绝的调用（包括 Client Capability 边界和 subagent admission 失败）继续使用普通 call/response lane
在首次明确使用 Computer Use 时，仅主动请求一次 macOS Accessibility 权限
覆盖真实 Desktop offer、协议边界、durable 拒绝路径与 native backend 授权请求

根因

Desktop 仅在 native backend 可用时发布 Computer Use offer。接入真实 maka-cu 后，其 draft-07 tuple schema 和工具描述超出了 Client Capability decoder 原有假设，导致注册失败，Host 最终只能暴露 Agent 和 Browser 两个工具组。

另一个问题出现在调用于 dispatch 前被拒绝时，包括 Client Capability 边界拒绝和 subagent admission 饱和：调用在 durable prepare 前已经获得 operation id，随后生成的 synthetic response 找不到对应 durable call，形成 orphan response 并使 Runtime Host 进入 draining。

此外，native 协议已经支持显式触发 Accessibility 授权，但 Maka 之前只执行静默检查。现在首次明确使用 Computer Use 时会请求一次授权，日常逐操作 preflight 仍保持静默。

验证

@maka/runtime：3179 passed，9 skipped
@maka/computer-use：134 passed
@maka/runtime-host：693 passed
@maka/desktop：1738 passed
Runtime、Runtime Host、Computer Use 与 Desktop typecheck
Biome 与 git diff --check
真实 host-backed Desktop 链路：发现 Desktop Computer Use 组、加载 maka_computer、完成 Accessibility 授权、调用 list_apps 并取得 native 应用列表

后续

native Screen Recording 主动授权由 maka-cu#1 跟踪

A pre-dispatch tool refusal used to kill the turn. The call event's lane was guessed when the event was built: an `operationId` claims the T1 dispatch protocol, so AgentRun skips the generic projection of that `function_call` and waits for `commitToolPrepared` — which sits after every refusal return. The call fact was never persisted, the synthetic result landed on the generic lane with nothing to attach to, and the ledger refused the `orphan_response` (apache#2234). apache#2233 closed that by predicting the refusals instead: every guard hoisted into a `preflightRejected` boolean read before the operationId. It is correct only while the prediction and the guards agree, and nothing holds them together — a new refusal path, or a guard that grows a condition its hoisted twin does not, silently restores the orphan. This decides the lane where it is known. `pushCallEvent('preflight'|'dispatch')` pushes at most once, every refusal routes through one `refuseBeforeDispatch` helper that keeps call and result together on the generic lane, and only `prepareDurableToolAttempt` asks for T1. The decision is the code path taken, so it cannot drift. apache#2233's predicate, its hoisted boundary read and its early slot reservation go with it; the boundary read and the reservation return to the guards they belong to, and everything else apache#2233 restored is untouched. Two things apache#2233 did not cover, both from the same failure: - A rejected append latched the RuntimeEvent store unavailable, and `commitTerminalRun` returns early on an unavailable store, so one refused event cost the run its own terminal write — a run stuck at `running` with no terminal event. `ToolLedgerRejectionError` now marks a refusal of one bad candidate against a healthy store, and only that skips the latch. An already corrupt ledger refuses well-formed writes for a different reason, so it throws `ToolLedgerCorruptionError` and keeps failing closed. - `agent_swarm`'s selector refusal said only "Provide exactly one of subagent_id or legacy profile", naming neither which of the two mistakes it was nor one value that would work — and the field list an args violation appends is the top-level one, not `items[n]` where the violation was. Tests: `pre-dispatch-refusal-ledger.test.ts` drives all seven refusal paths through the real `scanToolLedger`; on the tagged lane every one of them reproduces the production `orphan_response`. The terminal-write and ledger-corruption cases run against a `canonical` store, the only durability production ships. Refs apache#2234

A pre-dispatch tool refusal used to kill the turn. The call event's lane was guessed when the event was built: an `operationId` claims the T1 dispatch protocol, so AgentRun skips the generic projection of that `function_call` and waits for `commitToolPrepared` — which sits after every refusal return. The call fact was never persisted, the synthetic result landed on the generic lane with nothing to attach to, and the ledger refused the `orphan_response` (apache#2234). apache#2233 closed that by predicting the refusals instead: every guard hoisted into a `preflightRejected` boolean read before the operationId. It is correct only while the prediction and the guards agree, and nothing holds them together — a new refusal path, or a guard that grows a condition its hoisted twin does not, silently restores the orphan. This decides the lane where it is known. `pushCallEvent('preflight'|'dispatch')` pushes at most once, every refusal routes through one `refuseBeforeDispatch` helper that keeps call and result together on the generic lane, and only `prepareDurableToolAttempt` asks for T1. The decision is the code path taken, so it cannot drift. apache#2233's predicate, its hoisted boundary read and its early slot reservation go with it; the boundary read and the reservation return to the guards they belong to, and everything else apache#2233 restored is untouched. Two things apache#2233 did not cover, both from the same failure: - A rejected append latched the RuntimeEvent store unavailable, and `commitTerminalRun` returns early on an unavailable store, so one refused event cost the run its own terminal write — a run stuck at `running` with no terminal event. `ToolLedgerRejectionError` now marks a refusal of one bad candidate against a healthy store, and only that skips the latch. Damage found by the workspace health scan throws `ToolLedgerCorruptionError` and keeps failing closed. Be precise about what that second class buys, because the obvious rationale is wrong: the health scan runs only for tool-bearing events, so a damaged ledger refuses tool facts and would have taken the terminal event. The latch is what keeps it out, which reproduces apache#2234's shape for an already-damaged workspace. Left standing deliberately — it is a behaviour change on a path this commit does not otherwise touch — and tracked in apache#2313, with a test that pins the current price rather than hiding it. - `agent_swarm`'s selector refusal said only "Provide exactly one of subagent_id or legacy profile", naming neither which of the two mistakes it was nor one value that would work — and the field list an args violation appends is the top-level one, not `items[n]` where the violation was. Tests: `pre-dispatch-refusal-ledger.test.ts` drives all seven refusal paths through the real `scanToolLedger`; on the tagged lane every one of them reproduces the production `orphan_response`. The terminal-write and ledger-corruption cases run against a `canonical` store, the only durability production ships. Both error classes are pinned where they are produced, in `sqlite-runtime-store.test.ts`: their messages are byte-identical to the plain `Error` strings they replaced, so nothing else in that suite would notice a regression to `throw new Error(...)` — and the latch exemption would silently stop working. Refs apache#2234

…2240) A pre-dispatch tool refusal used to kill the turn. The call event's lane was guessed when the event was built: an `operationId` claims the T1 dispatch protocol, so AgentRun skips the generic projection of that `function_call` and waits for `commitToolPrepared` — which sits after every refusal return. The call fact was never persisted, the synthetic result landed on the generic lane with nothing to attach to, and the ledger refused the `orphan_response` (#2234). #2233 closed that by predicting the refusals instead: every guard hoisted into a `preflightRejected` boolean read before the operationId. It is correct only while the prediction and the guards agree, and nothing holds them together — a new refusal path, or a guard that grows a condition its hoisted twin does not, silently restores the orphan. This decides the lane where it is known. `pushCallEvent('preflight'|'dispatch')` pushes at most once, every refusal routes through one `refuseBeforeDispatch` helper that keeps call and result together on the generic lane, and only `prepareDurableToolAttempt` asks for T1. The decision is the code path taken, so it cannot drift. #2233's predicate, its hoisted boundary read and its early slot reservation go with it; the boundary read and the reservation return to the guards they belong to, and everything else #2233 restored is untouched. Two things #2233 did not cover, both from the same failure: - A rejected append latched the RuntimeEvent store unavailable, and `commitTerminalRun` returns early on an unavailable store, so one refused event cost the run its own terminal write — a run stuck at `running` with no terminal event. `ToolLedgerRejectionError` now marks a refusal of one bad candidate against a healthy store, and only that skips the latch. Damage found by the workspace health scan throws `ToolLedgerCorruptionError` and keeps failing closed. Be precise about what that second class buys, because the obvious rationale is wrong: the health scan runs only for tool-bearing events, so a damaged ledger refuses tool facts and would have taken the terminal event. The latch is what keeps it out, which reproduces #2234's shape for an already-damaged workspace. Left standing deliberately — it is a behaviour change on a path this commit does not otherwise touch — and tracked in #2313, with a test that pins the current price rather than hiding it. - `agent_swarm`'s selector refusal said only "Provide exactly one of subagent_id or legacy profile", naming neither which of the two mistakes it was nor one value that would work — and the field list an args violation appends is the top-level one, not `items[n]` where the violation was. Tests: `pre-dispatch-refusal-ledger.test.ts` drives all seven refusal paths through the real `scanToolLedger`; on the tagged lane every one of them reproduces the production `orphan_response`. The terminal-write and ledger-corruption cases run against a `canonical` store, the only durability production ships. Both error classes are pinned where they are produced, in `sqlite-runtime-store.test.ts`: their messages are byte-identical to the plain `Error` strings they replaced, so nothing else in that suite would notice a regression to `throw new Error(...)` — and the latch exemption would silently stop working. Refs #2234

M4n5ter · 2026-08-05T11:30:02Z

English

Summary

accept the real Desktop Computer Use tool schema in the Client Capability protocol
keep pre-dispatch rejections, including Client Capability boundary and subagent admission failures, on the generic call/response lane
request the native macOS Accessibility grant once, on the first explicit Computer Use attempt
cover the real Desktop offer, protocol boundary, durable rejection path, and native backend request

Root cause

Desktop only publishes its Computer Use offer when the native backend is available. Once a real maka-cu backend was present, its draft-07 tuple schemas and tool description exceeded assumptions in the Client Capability decoder, so registration failed and the Host exposed only the Agent and Browser groups.

A separate failure existed when a call was rejected before dispatch, including Client Capability boundary and saturated subagent admission failures: the call received a durable operation id before durable preparation. Its synthetic response then had no matching durable call, producing an orphan response and draining the Runtime Host.

Finally, the native protocol already supported an explicit Accessibility prompt, but Maka used only silent permission probes. The first explicit Computer Use attempt now requests that grant once while routine per-action preflight remains silent.

Validation

@maka/runtime: 3179 passed, 9 skipped
@maka/computer-use: 134 passed
@maka/runtime-host: 693 passed
@maka/desktop: 1738 passed
Runtime, Runtime Host, Computer Use, and Desktop type checks
Biome and git diff --check
real host-backed Desktop flow: discover the Desktop Computer Use group, load maka_computer, grant Accessibility, invoke list_apps, and receive the native app list

Follow-up

native Screen Recording consent is tracked in maka-cu#1

中文

概述

让 Client Capability 协议接受 Desktop Computer Use 的真实工具 schema
让 dispatch 前被拒绝的调用（包括 Client Capability 边界和 subagent admission 失败）继续使用普通 call/response lane
在首次明确使用 Computer Use 时，仅主动请求一次 macOS Accessibility 权限
覆盖真实 Desktop offer、协议边界、durable 拒绝路径与 native backend 授权请求

根因

Desktop 仅在 native backend 可用时发布 Computer Use offer。接入真实 maka-cu 后，其 draft-07 tuple schema 和工具描述超出了 Client Capability decoder 原有假设，导致注册失败，Host 最终只能暴露 Agent 和 Browser 两个工具组。

另一个问题出现在调用于 dispatch 前被拒绝时，包括 Client Capability 边界拒绝和 subagent admission 饱和：调用在 durable prepare 前已经获得 operation id，随后生成的 synthetic response 找不到对应 durable call，形成 orphan response 并使 Runtime Host 进入 draining。

此外，native 协议已经支持显式触发 Accessibility 授权，但 Maka 之前只执行静默检查。现在首次明确使用 Computer Use 时会请求一次授权，日常逐操作 preflight 仍保持静默。

验证

@maka/runtime：3179 passed，9 skipped
@maka/computer-use：134 passed
@maka/runtime-host：693 passed
@maka/desktop：1738 passed
Runtime、Runtime Host、Computer Use 与 Desktop typecheck
Biome 与 git diff --check
真实 host-backed Desktop 链路：发现 Desktop Computer Use 组、加载 maka_computer、完成 Accessibility 授权、调用 list_apps 并取得 native 应用列表

后续

native Screen Recording 主动授权由 maka-cu#1 跟踪

A pre-dispatch tool refusal used to kill the turn. The call event's lane was guessed when the event was built: an `operationId` claims the T1 dispatch protocol, so AgentRun skips the generic projection of that `function_call` and waits for `commitToolPrepared` — which sits after every refusal return. The call fact was never persisted, the synthetic result landed on the generic lane with nothing to attach to, and the ledger refused the `orphan_response` (apache#2234). apache#2233 closed that by predicting the refusals instead: every guard hoisted into a `preflightRejected` boolean read before the operationId. It is correct only while the prediction and the guards agree, and nothing holds them together — a new refusal path, or a guard that grows a condition its hoisted twin does not, silently restores the orphan. This decides the lane where it is known. `pushCallEvent('preflight'|'dispatch')` pushes at most once, every refusal routes through one `refuseBeforeDispatch` helper that keeps call and result together on the generic lane, and only `prepareDurableToolAttempt` asks for T1. The decision is the code path taken, so it cannot drift. apache#2233's predicate, its hoisted boundary read and its early slot reservation go with it; the boundary read and the reservation return to the guards they belong to, and everything else apache#2233 restored is untouched. Two things apache#2233 did not cover, both from the same failure: - A rejected append latched the RuntimeEvent store unavailable, and `commitTerminalRun` returns early on an unavailable store, so one refused event cost the run its own terminal write — a run stuck at `running` with no terminal event. `ToolLedgerRejectionError` now marks a refusal of one bad candidate against a healthy store, and only that skips the latch. An already corrupt ledger refuses well-formed writes for a different reason, so it throws `ToolLedgerCorruptionError` and keeps failing closed. - `agent_swarm`'s selector refusal said only "Provide exactly one of subagent_id or legacy profile", naming neither which of the two mistakes it was nor one value that would work — and the field list an args violation appends is the top-level one, not `items[n]` where the violation was. Tests: `pre-dispatch-refusal-ledger.test.ts` drives all seven refusal paths through the real `scanToolLedger`; on the tagged lane every one of them reproduces the production `orphan_response`. The terminal-write and ledger-corruption cases run against a `canonical` store, the only durability production ships. Refs apache#2234

A pre-dispatch tool refusal used to kill the turn. The call event's lane was guessed when the event was built: an `operationId` claims the T1 dispatch protocol, so AgentRun skips the generic projection of that `function_call` and waits for `commitToolPrepared` — which sits after every refusal return. The call fact was never persisted, the synthetic result landed on the generic lane with nothing to attach to, and the ledger refused the `orphan_response` (apache#2234). apache#2233 closed that by predicting the refusals instead: every guard hoisted into a `preflightRejected` boolean read before the operationId. It is correct only while the prediction and the guards agree, and nothing holds them together — a new refusal path, or a guard that grows a condition its hoisted twin does not, silently restores the orphan. This decides the lane where it is known. `pushCallEvent('preflight'|'dispatch')` pushes at most once, every refusal routes through one `refuseBeforeDispatch` helper that keeps call and result together on the generic lane, and only `prepareDurableToolAttempt` asks for T1. The decision is the code path taken, so it cannot drift. apache#2233's predicate, its hoisted boundary read and its early slot reservation go with it; the boundary read and the reservation return to the guards they belong to, and everything else apache#2233 restored is untouched. Two things apache#2233 did not cover, both from the same failure: - A rejected append latched the RuntimeEvent store unavailable, and `commitTerminalRun` returns early on an unavailable store, so one refused event cost the run its own terminal write — a run stuck at `running` with no terminal event. `ToolLedgerRejectionError` now marks a refusal of one bad candidate against a healthy store, and only that skips the latch. Damage found by the workspace health scan throws `ToolLedgerCorruptionError` and keeps failing closed. Be precise about what that second class buys, because the obvious rationale is wrong: the health scan runs only for tool-bearing events, so a damaged ledger refuses tool facts and would have taken the terminal event. The latch is what keeps it out, which reproduces apache#2234's shape for an already-damaged workspace. Left standing deliberately — it is a behaviour change on a path this commit does not otherwise touch — and tracked in apache#2313, with a test that pins the current price rather than hiding it. - `agent_swarm`'s selector refusal said only "Provide exactly one of subagent_id or legacy profile", naming neither which of the two mistakes it was nor one value that would work — and the field list an args violation appends is the top-level one, not `items[n]` where the violation was. Tests: `pre-dispatch-refusal-ledger.test.ts` drives all seven refusal paths through the real `scanToolLedger`; on the tagged lane every one of them reproduces the production `orphan_response`. The terminal-write and ledger-corruption cases run against a `canonical` store, the only durability production ships. Both error classes are pinned where they are produced, in `sqlite-runtime-store.test.ts`: their messages are byte-identical to the plain `Error` strings they replaced, so nothing else in that suite would notice a regression to `throw new Error(...)` — and the latch exemption would silently stop working. Refs apache#2234

…2240) A pre-dispatch tool refusal used to kill the turn. The call event's lane was guessed when the event was built: an `operationId` claims the T1 dispatch protocol, so AgentRun skips the generic projection of that `function_call` and waits for `commitToolPrepared` — which sits after every refusal return. The call fact was never persisted, the synthetic result landed on the generic lane with nothing to attach to, and the ledger refused the `orphan_response` (#2234). #2233 closed that by predicting the refusals instead: every guard hoisted into a `preflightRejected` boolean read before the operationId. It is correct only while the prediction and the guards agree, and nothing holds them together — a new refusal path, or a guard that grows a condition its hoisted twin does not, silently restores the orphan. This decides the lane where it is known. `pushCallEvent('preflight'|'dispatch')` pushes at most once, every refusal routes through one `refuseBeforeDispatch` helper that keeps call and result together on the generic lane, and only `prepareDurableToolAttempt` asks for T1. The decision is the code path taken, so it cannot drift. #2233's predicate, its hoisted boundary read and its early slot reservation go with it; the boundary read and the reservation return to the guards they belong to, and everything else #2233 restored is untouched. Two things #2233 did not cover, both from the same failure: - A rejected append latched the RuntimeEvent store unavailable, and `commitTerminalRun` returns early on an unavailable store, so one refused event cost the run its own terminal write — a run stuck at `running` with no terminal event. `ToolLedgerRejectionError` now marks a refusal of one bad candidate against a healthy store, and only that skips the latch. Damage found by the workspace health scan throws `ToolLedgerCorruptionError` and keeps failing closed. Be precise about what that second class buys, because the obvious rationale is wrong: the health scan runs only for tool-bearing events, so a damaged ledger refuses tool facts and would have taken the terminal event. The latch is what keeps it out, which reproduces #2234's shape for an already-damaged workspace. Left standing deliberately — it is a behaviour change on a path this commit does not otherwise touch — and tracked in #2313, with a test that pins the current price rather than hiding it. - `agent_swarm`'s selector refusal said only "Provide exactly one of subagent_id or legacy profile", naming neither which of the two mistakes it was nor one value that would work — and the field list an args violation appends is the top-level one, not `items[n]` where the violation was. Tests: `pre-dispatch-refusal-ledger.test.ts` drives all seven refusal paths through the real `scanToolLedger`; on the tagged lane every one of them reproduces the production `orphan_response`. The terminal-write and ledger-corruption cases run against a `canonical` store, the only durability production ships. Both error classes are pinned where they are produced, in `sqlite-runtime-store.test.ts`: their messages are byte-identical to the plain `Error` strings they replaced, so nothing else in that suite would notice a regression to `throw new Error(...)` — and the latch exemption would silently stop working. Refs #2234

M4n5ter · 2026-08-05T11:30:02Z

English

Summary

accept the real Desktop Computer Use tool schema in the Client Capability protocol
keep pre-dispatch rejections, including Client Capability boundary and subagent admission failures, on the generic call/response lane
request the native macOS Accessibility grant once, on the first explicit Computer Use attempt
cover the real Desktop offer, protocol boundary, durable rejection path, and native backend request

Root cause

Desktop only publishes its Computer Use offer when the native backend is available. Once a real maka-cu backend was present, its draft-07 tuple schemas and tool description exceeded assumptions in the Client Capability decoder, so registration failed and the Host exposed only the Agent and Browser groups.

A separate failure existed when a call was rejected before dispatch, including Client Capability boundary and saturated subagent admission failures: the call received a durable operation id before durable preparation. Its synthetic response then had no matching durable call, producing an orphan response and draining the Runtime Host.

Finally, the native protocol already supported an explicit Accessibility prompt, but Maka used only silent permission probes. The first explicit Computer Use attempt now requests that grant once while routine per-action preflight remains silent.

Validation

@maka/runtime: 3179 passed, 9 skipped
@maka/computer-use: 134 passed
@maka/runtime-host: 693 passed
@maka/desktop: 1738 passed
Runtime, Runtime Host, Computer Use, and Desktop type checks
Biome and git diff --check
real host-backed Desktop flow: discover the Desktop Computer Use group, load maka_computer, grant Accessibility, invoke list_apps, and receive the native app list

Follow-up

native Screen Recording consent is tracked in maka-cu#1

中文

概述

让 Client Capability 协议接受 Desktop Computer Use 的真实工具 schema
让 dispatch 前被拒绝的调用（包括 Client Capability 边界和 subagent admission 失败）继续使用普通 call/response lane
在首次明确使用 Computer Use 时，仅主动请求一次 macOS Accessibility 权限
覆盖真实 Desktop offer、协议边界、durable 拒绝路径与 native backend 授权请求

根因

Desktop 仅在 native backend 可用时发布 Computer Use offer。接入真实 maka-cu 后，其 draft-07 tuple schema 和工具描述超出了 Client Capability decoder 原有假设，导致注册失败，Host 最终只能暴露 Agent 和 Browser 两个工具组。

另一个问题出现在调用于 dispatch 前被拒绝时，包括 Client Capability 边界拒绝和 subagent admission 饱和：调用在 durable prepare 前已经获得 operation id，随后生成的 synthetic response 找不到对应 durable call，形成 orphan response 并使 Runtime Host 进入 draining。

此外，native 协议已经支持显式触发 Accessibility 授权，但 Maka 之前只执行静默检查。现在首次明确使用 Computer Use 时会请求一次授权，日常逐操作 preflight 仍保持静默。

验证

@maka/runtime：3179 passed，9 skipped
@maka/computer-use：134 passed
@maka/runtime-host：693 passed
@maka/desktop：1738 passed
Runtime、Runtime Host、Computer Use 与 Desktop typecheck
Biome 与 git diff --check
真实 host-backed Desktop 链路：发现 Desktop Computer Use 组、加载 maka_computer、完成 Accessibility 授权、调用 list_apps 并取得 native 应用列表

后续

native Screen Recording 主动授权由 maka-cu#1 跟踪

A pre-dispatch tool refusal used to kill the turn. The call event's lane was guessed when the event was built: an `operationId` claims the T1 dispatch protocol, so AgentRun skips the generic projection of that `function_call` and waits for `commitToolPrepared` — which sits after every refusal return. The call fact was never persisted, the synthetic result landed on the generic lane with nothing to attach to, and the ledger refused the `orphan_response` (apache#2234). apache#2233 closed that by predicting the refusals instead: every guard hoisted into a `preflightRejected` boolean read before the operationId. It is correct only while the prediction and the guards agree, and nothing holds them together — a new refusal path, or a guard that grows a condition its hoisted twin does not, silently restores the orphan. This decides the lane where it is known. `pushCallEvent('preflight'|'dispatch')` pushes at most once, every refusal routes through one `refuseBeforeDispatch` helper that keeps call and result together on the generic lane, and only `prepareDurableToolAttempt` asks for T1. The decision is the code path taken, so it cannot drift. apache#2233's predicate, its hoisted boundary read and its early slot reservation go with it; the boundary read and the reservation return to the guards they belong to, and everything else apache#2233 restored is untouched. Two things apache#2233 did not cover, both from the same failure: - A rejected append latched the RuntimeEvent store unavailable, and `commitTerminalRun` returns early on an unavailable store, so one refused event cost the run its own terminal write — a run stuck at `running` with no terminal event. `ToolLedgerRejectionError` now marks a refusal of one bad candidate against a healthy store, and only that skips the latch. An already corrupt ledger refuses well-formed writes for a different reason, so it throws `ToolLedgerCorruptionError` and keeps failing closed. - `agent_swarm`'s selector refusal said only "Provide exactly one of subagent_id or legacy profile", naming neither which of the two mistakes it was nor one value that would work — and the field list an args violation appends is the top-level one, not `items[n]` where the violation was. Tests: `pre-dispatch-refusal-ledger.test.ts` drives all seven refusal paths through the real `scanToolLedger`; on the tagged lane every one of them reproduces the production `orphan_response`. The terminal-write and ledger-corruption cases run against a `canonical` store, the only durability production ships. Refs apache#2234

A pre-dispatch tool refusal used to kill the turn. The call event's lane was guessed when the event was built: an `operationId` claims the T1 dispatch protocol, so AgentRun skips the generic projection of that `function_call` and waits for `commitToolPrepared` — which sits after every refusal return. The call fact was never persisted, the synthetic result landed on the generic lane with nothing to attach to, and the ledger refused the `orphan_response` (apache#2234). apache#2233 closed that by predicting the refusals instead: every guard hoisted into a `preflightRejected` boolean read before the operationId. It is correct only while the prediction and the guards agree, and nothing holds them together — a new refusal path, or a guard that grows a condition its hoisted twin does not, silently restores the orphan. This decides the lane where it is known. `pushCallEvent('preflight'|'dispatch')` pushes at most once, every refusal routes through one `refuseBeforeDispatch` helper that keeps call and result together on the generic lane, and only `prepareDurableToolAttempt` asks for T1. The decision is the code path taken, so it cannot drift. apache#2233's predicate, its hoisted boundary read and its early slot reservation go with it; the boundary read and the reservation return to the guards they belong to, and everything else apache#2233 restored is untouched. Two things apache#2233 did not cover, both from the same failure: - A rejected append latched the RuntimeEvent store unavailable, and `commitTerminalRun` returns early on an unavailable store, so one refused event cost the run its own terminal write — a run stuck at `running` with no terminal event. `ToolLedgerRejectionError` now marks a refusal of one bad candidate against a healthy store, and only that skips the latch. Damage found by the workspace health scan throws `ToolLedgerCorruptionError` and keeps failing closed. Be precise about what that second class buys, because the obvious rationale is wrong: the health scan runs only for tool-bearing events, so a damaged ledger refuses tool facts and would have taken the terminal event. The latch is what keeps it out, which reproduces apache#2234's shape for an already-damaged workspace. Left standing deliberately — it is a behaviour change on a path this commit does not otherwise touch — and tracked in apache#2313, with a test that pins the current price rather than hiding it. - `agent_swarm`'s selector refusal said only "Provide exactly one of subagent_id or legacy profile", naming neither which of the two mistakes it was nor one value that would work — and the field list an args violation appends is the top-level one, not `items[n]` where the violation was. Tests: `pre-dispatch-refusal-ledger.test.ts` drives all seven refusal paths through the real `scanToolLedger`; on the tagged lane every one of them reproduces the production `orphan_response`. The terminal-write and ledger-corruption cases run against a `canonical` store, the only durability production ships. Both error classes are pinned where they are produced, in `sqlite-runtime-store.test.ts`: their messages are byte-identical to the plain `Error` strings they replaced, so nothing else in that suite would notice a regression to `throw new Error(...)` — and the latch exemption would silently stop working. Refs apache#2234

…2240) A pre-dispatch tool refusal used to kill the turn. The call event's lane was guessed when the event was built: an `operationId` claims the T1 dispatch protocol, so AgentRun skips the generic projection of that `function_call` and waits for `commitToolPrepared` — which sits after every refusal return. The call fact was never persisted, the synthetic result landed on the generic lane with nothing to attach to, and the ledger refused the `orphan_response` (#2234). #2233 closed that by predicting the refusals instead: every guard hoisted into a `preflightRejected` boolean read before the operationId. It is correct only while the prediction and the guards agree, and nothing holds them together — a new refusal path, or a guard that grows a condition its hoisted twin does not, silently restores the orphan. This decides the lane where it is known. `pushCallEvent('preflight'|'dispatch')` pushes at most once, every refusal routes through one `refuseBeforeDispatch` helper that keeps call and result together on the generic lane, and only `prepareDurableToolAttempt` asks for T1. The decision is the code path taken, so it cannot drift. #2233's predicate, its hoisted boundary read and its early slot reservation go with it; the boundary read and the reservation return to the guards they belong to, and everything else #2233 restored is untouched. Two things #2233 did not cover, both from the same failure: - A rejected append latched the RuntimeEvent store unavailable, and `commitTerminalRun` returns early on an unavailable store, so one refused event cost the run its own terminal write — a run stuck at `running` with no terminal event. `ToolLedgerRejectionError` now marks a refusal of one bad candidate against a healthy store, and only that skips the latch. Damage found by the workspace health scan throws `ToolLedgerCorruptionError` and keeps failing closed. Be precise about what that second class buys, because the obvious rationale is wrong: the health scan runs only for tool-bearing events, so a damaged ledger refuses tool facts and would have taken the terminal event. The latch is what keeps it out, which reproduces #2234's shape for an already-damaged workspace. Left standing deliberately — it is a behaviour change on a path this commit does not otherwise touch — and tracked in #2313, with a test that pins the current price rather than hiding it. - `agent_swarm`'s selector refusal said only "Provide exactly one of subagent_id or legacy profile", naming neither which of the two mistakes it was nor one value that would work — and the field list an args violation appends is the top-level one, not `items[n]` where the violation was. Tests: `pre-dispatch-refusal-ledger.test.ts` drives all seven refusal paths through the real `scanToolLedger`; on the tagged lane every one of them reproduces the production `orphan_response`. The terminal-write and ledger-corruption cases run against a `canonical` store, the only durability production ships. Both error classes are pinned where they are produced, in `sqlite-runtime-store.test.ts`: their messages are byte-identical to the plain `Error` strings they replaced, so nothing else in that suite would notice a regression to `throw new Error(...)` — and the latch exemption would silently stop working. Refs #2234

M4n5ter · 2026-08-05T11:30:02Z

English

Summary

accept the real Desktop Computer Use tool schema in the Client Capability protocol
keep pre-dispatch rejections, including Client Capability boundary and subagent admission failures, on the generic call/response lane
request the native macOS Accessibility grant once, on the first explicit Computer Use attempt
cover the real Desktop offer, protocol boundary, durable rejection path, and native backend request

Root cause

Desktop only publishes its Computer Use offer when the native backend is available. Once a real maka-cu backend was present, its draft-07 tuple schemas and tool description exceeded assumptions in the Client Capability decoder, so registration failed and the Host exposed only the Agent and Browser groups.

A separate failure existed when a call was rejected before dispatch, including Client Capability boundary and saturated subagent admission failures: the call received a durable operation id before durable preparation. Its synthetic response then had no matching durable call, producing an orphan response and draining the Runtime Host.

Finally, the native protocol already supported an explicit Accessibility prompt, but Maka used only silent permission probes. The first explicit Computer Use attempt now requests that grant once while routine per-action preflight remains silent.

Validation

@maka/runtime: 3179 passed, 9 skipped
@maka/computer-use: 134 passed
@maka/runtime-host: 693 passed
@maka/desktop: 1738 passed
Runtime, Runtime Host, Computer Use, and Desktop type checks
Biome and git diff --check
real host-backed Desktop flow: discover the Desktop Computer Use group, load maka_computer, grant Accessibility, invoke list_apps, and receive the native app list

Follow-up

native Screen Recording consent is tracked in maka-cu#1

中文

概述

让 Client Capability 协议接受 Desktop Computer Use 的真实工具 schema
让 dispatch 前被拒绝的调用（包括 Client Capability 边界和 subagent admission 失败）继续使用普通 call/response lane
在首次明确使用 Computer Use 时，仅主动请求一次 macOS Accessibility 权限
覆盖真实 Desktop offer、协议边界、durable 拒绝路径与 native backend 授权请求

根因

Desktop 仅在 native backend 可用时发布 Computer Use offer。接入真实 maka-cu 后，其 draft-07 tuple schema 和工具描述超出了 Client Capability decoder 原有假设，导致注册失败，Host 最终只能暴露 Agent 和 Browser 两个工具组。

另一个问题出现在调用于 dispatch 前被拒绝时，包括 Client Capability 边界拒绝和 subagent admission 饱和：调用在 durable prepare 前已经获得 operation id，随后生成的 synthetic response 找不到对应 durable call，形成 orphan response 并使 Runtime Host 进入 draining。

此外，native 协议已经支持显式触发 Accessibility 授权，但 Maka 之前只执行静默检查。现在首次明确使用 Computer Use 时会请求一次授权，日常逐操作 preflight 仍保持静默。

验证

@maka/runtime：3179 passed，9 skipped
@maka/computer-use：134 passed
@maka/runtime-host：693 passed
@maka/desktop：1738 passed
Runtime、Runtime Host、Computer Use 与 Desktop typecheck
Biome 与 git diff --check
真实 host-backed Desktop 链路：发现 Desktop Computer Use 组、加载 maka_computer、完成 Accessibility 授权、调用 list_apps 并取得 native 应用列表

后续

native Screen Recording 主动授权由 maka-cu#1 跟踪

A pre-dispatch tool refusal used to kill the turn. The call event's lane was guessed when the event was built: an `operationId` claims the T1 dispatch protocol, so AgentRun skips the generic projection of that `function_call` and waits for `commitToolPrepared` — which sits after every refusal return. The call fact was never persisted, the synthetic result landed on the generic lane with nothing to attach to, and the ledger refused the `orphan_response` (apache#2234). apache#2233 closed that by predicting the refusals instead: every guard hoisted into a `preflightRejected` boolean read before the operationId. It is correct only while the prediction and the guards agree, and nothing holds them together — a new refusal path, or a guard that grows a condition its hoisted twin does not, silently restores the orphan. This decides the lane where it is known. `pushCallEvent('preflight'|'dispatch')` pushes at most once, every refusal routes through one `refuseBeforeDispatch` helper that keeps call and result together on the generic lane, and only `prepareDurableToolAttempt` asks for T1. The decision is the code path taken, so it cannot drift. apache#2233's predicate, its hoisted boundary read and its early slot reservation go with it; the boundary read and the reservation return to the guards they belong to, and everything else apache#2233 restored is untouched. Two things apache#2233 did not cover, both from the same failure: - A rejected append latched the RuntimeEvent store unavailable, and `commitTerminalRun` returns early on an unavailable store, so one refused event cost the run its own terminal write — a run stuck at `running` with no terminal event. `ToolLedgerRejectionError` now marks a refusal of one bad candidate against a healthy store, and only that skips the latch. An already corrupt ledger refuses well-formed writes for a different reason, so it throws `ToolLedgerCorruptionError` and keeps failing closed. - `agent_swarm`'s selector refusal said only "Provide exactly one of subagent_id or legacy profile", naming neither which of the two mistakes it was nor one value that would work — and the field list an args violation appends is the top-level one, not `items[n]` where the violation was. Tests: `pre-dispatch-refusal-ledger.test.ts` drives all seven refusal paths through the real `scanToolLedger`; on the tagged lane every one of them reproduces the production `orphan_response`. The terminal-write and ledger-corruption cases run against a `canonical` store, the only durability production ships. Refs apache#2234

A pre-dispatch tool refusal used to kill the turn. The call event's lane was guessed when the event was built: an `operationId` claims the T1 dispatch protocol, so AgentRun skips the generic projection of that `function_call` and waits for `commitToolPrepared` — which sits after every refusal return. The call fact was never persisted, the synthetic result landed on the generic lane with nothing to attach to, and the ledger refused the `orphan_response` (apache#2234). apache#2233 closed that by predicting the refusals instead: every guard hoisted into a `preflightRejected` boolean read before the operationId. It is correct only while the prediction and the guards agree, and nothing holds them together — a new refusal path, or a guard that grows a condition its hoisted twin does not, silently restores the orphan. This decides the lane where it is known. `pushCallEvent('preflight'|'dispatch')` pushes at most once, every refusal routes through one `refuseBeforeDispatch` helper that keeps call and result together on the generic lane, and only `prepareDurableToolAttempt` asks for T1. The decision is the code path taken, so it cannot drift. apache#2233's predicate, its hoisted boundary read and its early slot reservation go with it; the boundary read and the reservation return to the guards they belong to, and everything else apache#2233 restored is untouched. Two things apache#2233 did not cover, both from the same failure: - A rejected append latched the RuntimeEvent store unavailable, and `commitTerminalRun` returns early on an unavailable store, so one refused event cost the run its own terminal write — a run stuck at `running` with no terminal event. `ToolLedgerRejectionError` now marks a refusal of one bad candidate against a healthy store, and only that skips the latch. Damage found by the workspace health scan throws `ToolLedgerCorruptionError` and keeps failing closed. Be precise about what that second class buys, because the obvious rationale is wrong: the health scan runs only for tool-bearing events, so a damaged ledger refuses tool facts and would have taken the terminal event. The latch is what keeps it out, which reproduces apache#2234's shape for an already-damaged workspace. Left standing deliberately — it is a behaviour change on a path this commit does not otherwise touch — and tracked in apache#2313, with a test that pins the current price rather than hiding it. - `agent_swarm`'s selector refusal said only "Provide exactly one of subagent_id or legacy profile", naming neither which of the two mistakes it was nor one value that would work — and the field list an args violation appends is the top-level one, not `items[n]` where the violation was. Tests: `pre-dispatch-refusal-ledger.test.ts` drives all seven refusal paths through the real `scanToolLedger`; on the tagged lane every one of them reproduces the production `orphan_response`. The terminal-write and ledger-corruption cases run against a `canonical` store, the only durability production ships. Both error classes are pinned where they are produced, in `sqlite-runtime-store.test.ts`: their messages are byte-identical to the plain `Error` strings they replaced, so nothing else in that suite would notice a regression to `throw new Error(...)` — and the latch exemption would silently stop working. Refs apache#2234

…2240) A pre-dispatch tool refusal used to kill the turn. The call event's lane was guessed when the event was built: an `operationId` claims the T1 dispatch protocol, so AgentRun skips the generic projection of that `function_call` and waits for `commitToolPrepared` — which sits after every refusal return. The call fact was never persisted, the synthetic result landed on the generic lane with nothing to attach to, and the ledger refused the `orphan_response` (#2234). #2233 closed that by predicting the refusals instead: every guard hoisted into a `preflightRejected` boolean read before the operationId. It is correct only while the prediction and the guards agree, and nothing holds them together — a new refusal path, or a guard that grows a condition its hoisted twin does not, silently restores the orphan. This decides the lane where it is known. `pushCallEvent('preflight'|'dispatch')` pushes at most once, every refusal routes through one `refuseBeforeDispatch` helper that keeps call and result together on the generic lane, and only `prepareDurableToolAttempt` asks for T1. The decision is the code path taken, so it cannot drift. #2233's predicate, its hoisted boundary read and its early slot reservation go with it; the boundary read and the reservation return to the guards they belong to, and everything else #2233 restored is untouched. Two things #2233 did not cover, both from the same failure: - A rejected append latched the RuntimeEvent store unavailable, and `commitTerminalRun` returns early on an unavailable store, so one refused event cost the run its own terminal write — a run stuck at `running` with no terminal event. `ToolLedgerRejectionError` now marks a refusal of one bad candidate against a healthy store, and only that skips the latch. Damage found by the workspace health scan throws `ToolLedgerCorruptionError` and keeps failing closed. Be precise about what that second class buys, because the obvious rationale is wrong: the health scan runs only for tool-bearing events, so a damaged ledger refuses tool facts and would have taken the terminal event. The latch is what keeps it out, which reproduces #2234's shape for an already-damaged workspace. Left standing deliberately — it is a behaviour change on a path this commit does not otherwise touch — and tracked in #2313, with a test that pins the current price rather than hiding it. - `agent_swarm`'s selector refusal said only "Provide exactly one of subagent_id or legacy profile", naming neither which of the two mistakes it was nor one value that would work — and the field list an args violation appends is the top-level one, not `items[n]` where the violation was. Tests: `pre-dispatch-refusal-ledger.test.ts` drives all seven refusal paths through the real `scanToolLedger`; on the tagged lane every one of them reproduces the production `orphan_response`. The terminal-write and ledger-corruption cases run against a `canonical` store, the only durability production ships. Both error classes are pinned where they are produced, in `sqlite-runtime-store.test.ts`: their messages are byte-identical to the plain `Error` strings they replaced, so nothing else in that suite would notice a regression to `throw new Error(...)` — and the latch exemption would silently stop working. Refs #2234

fix(runtime-host): restore desktop computer use capability
bb9ed11

M4n5ter mentioned this pull request Aug 5, 2026
Add an explicit Screen Recording permission request to the host protocol maka-agent/maka-cu#1
Open

fix(runtime): keep subagent admission rejections generic
23d338b

M4n5ter marked this pull request as ready for review August 5, 2026 11:58

M4n5ter merged commit f8d2ac4 into mainAug 5, 2026
12 checks passed

M4n5ter deleted the fix/runtime-host-computer-use-capability branch August 5, 2026 11:58

Astro-Han mentioned this pull request Aug 5, 2026
fix(runtime): decide the tool call event's ledger lane at push time #2240
Merged

M4n5ter mentioned this pull request Aug 6, 2026
[Tracking] Runtime Host M4 Desktop-first client adapters #2010
Closed

MoonOld mentioned this pull request Aug 17, 2026
bug(runtime): every pre-dispatch tool refusal kills the turn — the synthetic result lands as an orphan_response the ledger rejects #2234
Closed