fix(cu): let a model read back the Computer Use call it actually made

[hqhq1025]

The record a model reads back of its own Computer Use call was the host's
approval projection, not the call. model-history.ts replays
event.content.args, and those args came from computerUseApprovalSummary,
which exists to decide and display a permission: it renames window_id to
windowId, adds approvalClass and rememberForTurnAllowed, and drops every
argument it does not need.

Measured on the real ToolRuntime, a model that sent

{"action":"press_key","app":"TextEdit","window_id":41,
"observation_id":"obs-7","element_id":"e12","text":"cmd+s"}

read back

{"action":"press_key","approvalClass":"keyboard_mutation",
"rememberForTurnAllowed":true,"app":"TextEdit","windowId":41,
"observationId":"obs-7"}

— a key the tool rejects, two fields it never sent, no element, and a
press_key with no key. A model imitates the shape it is shown, so it went on
calling it that way; a real desktop run failed six of eleven calls on shapes
copied from its own history.

This adds computerUseModelCallArgs: the same privacy rule, in the names the
tool accepts, and wires it at tool-runtime.ts, which is the line every
shipping backend goes through. The permission prompt still reads
permissionArgs and the approval scope key is still computed from the raw
call, so only what is written down changes.

What now crosses the privacy boundary

computer-use-privacy-boundary.test.ts asserted this line before this PR, and
it is updated in place rather than around, so the change is visible in the
diff. Two things cross that did not:

• element_id — an index the model chose into an observation it had already
  read (e12). Admitted only when it is a stable identifier, so an
  accessibility label arriving under that key is dropped rather than persisted.
  Without it, ten element actions in a turn are indistinguishable.
• coordinate, start_coordinate, region — geometry the model wrote into
  the call itself. Integers only, so a mistyped value still degrades to a
  shape. A coordinate is not read off the screen; withholding it leaves a model
  that clicked a point and missed unable to see that it had already tried that
  point.

What still does not cross: the value of text for type and select_text,
the value of set_value, and every other argument whose value is screen
content or something a person asked to have typed. Those keep their key and
lose their value to <text> — the key has to stay, or the model reads its own
history as a call it never made. text for press_key, key, hold_key and
secondary_action is a name from a closed set the executor publishes, so it is
carried: one argument name meaning six things, and only two of the six come
from outside the model.

element_identity joins approvalClass and rememberForTurnAllowed as
host-only. The Computer Use tool's own permissionArgs resolves the model's
element_id against the live observation and attaches it, and permissionArgs
is what this projection runs on.

Also here

COMPUTER_USE_SEMANTIC_ACTIONS replaces a hand-written action list that had
already drifted: window_action was added to the strict union and not to the
list, so every window move, resize and minimise would have summarised as
unknown — in the approval a person reads, and in the record the model reads
back. computer-use-schema-parity.test.ts now compares the two in both
directions.

Relationship to #1888

#1888 reached the same conclusion from the renderer's side and carried
elementId in the approval summary so its labels could tell two element rows
apart. That intent is subsumed here: element_id is carried, in the tool's own
casing. When the two are merged, #1888's computer-action-label.ts should read
window_id and element_id rather than windowId and elementId, and the
elementId case it added to computer-use-privacy-boundary.test.ts is covered
by the projection assertion in this branch.

Not here any more

The executor capability declarations this PR was originally titled for were
removed in 0fcfb46: nothing produced them, so they were a type surface with
no writer. The title and this description are rewritten to match what the
branch actually does.

Verification

The new assertion is on the tool_start event, not on the projection function.
Reverted to computerUseApprovalSummary at tool-runtime.ts and rebuilt, it
fails with exactly the diff quoted above; restored, it passes. A test that
calls computerUseModelCallArgs directly stays green either way, which is how
this survived being fixed once already in PiAgentBackend — a backend the
desktop app never instantiates.

@maka/core and @maka/runtime suites pass; npx biome check clean on the
touched files; node scripts/check-console.mjs passes. Rebased onto current
main, cleanly.

[hqhq1025]

Pushed fixes for all six findings. The claim in the PR body that nothing behaves differently was wrong, and finding 1 was the reason.

Finding 1, resolution: I scoped the constant to what main's schema accepts rather than stacking the PR on the executor branch. Verified first — main's wire enum at computer-use-tools.ts is list_apps, observe, click_element, set_value, select_text, secondary_action, press_key plus CU_ACTION_TYPES, and none of launch_app, scroll_element, element_sequence or window_action is in it. The four names went into APPROVAL_ACTIONS through COMPUTER_USE_SEMANTIC_ACTIONS, so computerUseApprovalSummary flipped knownAction to true for calls the SDK rejects before the tool runs, and rememberForTurnAllowed could evaluate true for the two that also joined SEMANTIC_ACTIONS. I chose scoping over stacking for two reasons. The constant's stated purpose is to be held against the tool schema, so declaring names the schema does not have is the same drift it exists to prevent, only in the direction nothing was checking. And stacking would make the PR unmergeable until the executor lands, which delays the parts that are correct today. The executor's vocabulary belongs on the branch that also ships the executor.

Finding 2: the promised file did not exist, but a guard did — computer-use-schema-parity.test.ts, added in #1870 after this branch was cut. It only walks from the schemas to the catalog, which catches a missing name and not an extra one, so the widening in finding 1 would have passed it. I added the reverse comparison to that file rather than creating the second one the comment named, and corrected the comment to point at the real file. Negative control: reintroducing the four names turns the new check red and it names all four. There is also an in-file control that runs the same comparator over a fixed catalog, so it keeps proving the comparator can return something on the day the real catalog is correct.

Finding 3: confirmed. Only COMPUTER_USE_SEMANTIC_ACTIONS was exported, so computerUseModelCallArgs was unreachable from @maka/runtime and the whole headline fix was dead code while the harmful widening was the only part that shipped. The five missing symbols are exported now, and the projection is wired into projectPiToolArgs in pi-agent-backend.ts, which writes the persisted tool_call message and the tool_start event. Negative control: reverting that one line turns the pi-agent-backend projection test red with the approval dialect back in the diff.

Finding 4: confirmed and dropped rather than wired. ComputerUseSettings appears in none of AppSettings, UpdateAppSettingsInput, the defaults, the merge or the normalize pass, unlike every peer settings module, and select-backend.ts assembles the CU tools with no enable check anywhere. A type that says enabled: false while the shipped app always has it on is worse than no type. Wiring a real switch needs a UI and a migration and does not belong under a types commit.

Finding 5: confirmed, and it is exactly as described. text is six arguments under one name — the key for press_key, key and hold_key, the element action name for secondary_action, a screen substring for select_text, typed content for type. MODEL_CALL_PLAIN_VALUES is now a map from action to the argument names that are plain for that action. An action the tool does not accept has no entry, so it falls through to shapes rather than to whichever set was used last. Negative control: reverting to the name-keyed set turns two tests red, showing press_key coming back as text: .

Finding 6, partially rejected with evidence. dispatch_refused is gone. It is not a declaration — COMPUTER_USE_ERROR_CODES is a runtime value feeding isComputerUseErrorCode, which decides at cua-driver-result.ts:88 whether a raw string from the driver process is trusted or replaced with capture_failed. Widening that with no producer is a live change. The other five named items are different in kind. messageIsAppTextFree, truncated, actions, subrole and placeholder are optional fields on TypeScript interfaces with no runtime effect, and they are not distinguishable from about ten other unproduced declarations in the same diff that the review accepted — focused, appAlias, obscuringRects, menu, query, CuLaunchedApp, scroll_element, window_action, launchApp. Dropping the named five and keeping those would be arbitrary; dropping all of them empties the branch of its purpose. Declaring the shape an executor returns is what this branch is for, so they stay, and the absent-means-withheld polarity on messageIsAppTextFree is kept as suggested.

Also rebased onto current main, which the branch was one commit behind — the missing commit was #1870, the parity test finding 2 turns out to depend on.

Test delta, measured against a baseline taken on clean origin/main on the same machine. This machine's Node has no node:sqlite, so @maka/runtime carries 64 pre-existing failing test names there. After the change: 2722 tests, zero new failures and zero fixed against that set. @maka/core goes 703/703 to 710/710, the seven new ones being the model-call projection tests. biome check clean on the six touched files, check-console passes.

[hqhq1025]

Second-round review addressed. Two findings fixed, one dropped after checking, one scope decision.

Coordinates are back. The doc said typed text, written values and coordinates are screen-derived and stay out, and that is false for the third one: a coordinate is the model's own output, four digits it chose and sent. Reduced to <point>, a model that clicked [412, 88] and missed could not tell whether it had already tried that point, which is the repeated-call shape this projection exists to make visible. coordinate, start_coordinate and region now come back whole when they are integers and still degrade to a shape when they are not, so a malformed argument does not become a leak channel.

The out-of-enum action is reported as sent. On the AI SDK path the question is moot — a schema-rejected call never produces a tool-call part, so settleToolCall is never reached and no tool_start is emitted. But this projection's only consumer is the Pi backend, where tool_start arrives as a transport frame that Maka does not validate, so the case is live there. It is also wrong in principle: this record is the model's own arguments, and the action is one of them. Collapsing an unrecognised name is computerUseApprovalSummary's job, where knownAction decides what a person is asked to allow; a test now pins that the two functions disagree on purpose. The action is bounded and redacted like every other model-supplied string.

The declared-and-unconsumed set is dropped. launchApp, CuLaunchedApp, truncated, actions, subrole, placeholder, focused, menu, query, appAlias, obscuringRects, targetWindowId, targetStacking, messageIsAppTextFree, and the scroll_element and window_action members of CuSemanticAction — zero producers and zero consumers, confirmed by grep across packages and apps. The reason is the parity guard's own header: window_action sat in the strict union and not on the wire, was unreachable from the day it shipped, and nothing failed, because a declaration with no producer has nothing to check it. This branch was putting window_action back into that state with scroll_element beside it. computer-use-types.ts is now byte-identical to main; the additions come with the executor that produces them, where a guard can assert they arrive. The PR body has been rewritten so it no longer claims them.

What is left is what has a consumer: COMPUTER_USE_SEMANTIC_ACTIONS with the two-way parity check, and computerUseModelCallArgs wired into the Pi backend.

Negative controls, run rather than asserted. Reverting the geometry branch turned the coordinate tests red on coordinate: '<point>' against [412, 88]; restoring the APPROVAL_ACTIONS gate on action turned the third red on unknown against element_sequence, and the Pi backend's own projection test with it. Both back to green after restoring.

One thing I did not change, because it is outside this branch: tool-runtime.ts:776 still writes computerUseApprovalSummary(permissionArgs) into both the tool_start event and the persisted tool_call message on the AI SDK path. That is the same defect this PR fixes, on the main backend rather than the Pi one. It needs its own change, since the same value also feeds describeToolIntent, the durable args hash and the approval record.

Test delta against a clean rebuild of main on this machine: none in packages/core or the Computer Use tests. The rest of the run is shell, filesystem and host-process timing under load 40 on this box; each one passes when its file is run alone.

[hqhq1025]

Blocking finding addressed: the fix is moved to the path the shipping app runs.

It was wired into PiAgentBackend, which the desktop app never instantiates.
boot.ts registers only ai-sdk and fake; the pi backend is reachable only from
harbor-cell.ts behind MAKA_PI_*, driving an external CLI, and it does not
construct a ToolRuntime at all. tool-runtime.ts had a zero-byte diff, so on the
shipping path nothing changed. Measured on the real ToolRuntime, a model that
sent action press_key with app, window_id 41, observation_id obs-7, element_id
e12 and text cmd+s read back action, approvalClass, rememberForTurnAllowed,
app, windowId 41, observationId — a key the tool rejects, two fields it never
sent, no element, and a press_key with no key. That is now the one line the PR
changes in production.

The new assertion is on the tool_start event, which is what model-history.ts
replays, rather than on the projection function. Reverted to
computerUseApprovalSummary and rebuilt, it fails with exactly the diff above;
restored, it passes. A test calling computerUseModelCallArgs directly stays
green either way, which is how this survived being fixed once already.

On the coupling with #1888 and the privacy boundary, since the description
asked that it not be resolved silently.

computer-use-privacy-boundary.test.ts is not new to #1888; it has asserted this
line since #1581, and #1888 added an elementId case to it. Both PRs are
therefore changing the same invariant, and this one changes it in place rather
than around it, so what crosses is visible in the diff and is spelled out in
the file, the commit message and the PR body.

Two things now cross. element_id, which is an index the model chose into an
observation it had already read, admitted only when it is a stable identifier
so an accessibility label arriving under that key is dropped — this is exactly
what #1888 wanted and it is subsumed here, in the tool's own casing.
coordinate, start_coordinate and region, which are geometry the model wrote
into the call itself, integers only so a mistyped value still degrades to a
shape.

The argument for carrying coordinates is that they are the model's own output,
already present in the assistant turn that produced them, and that withholding
them leaves a model that clicked a point and missed unable to see that it had
already tried that point. The argument against, that for set_value and type
these are what the user was having typed on their behalf, does not apply to
coordinates: it applies to text and value, and those still do not cross. They
keep their key and lose their value to , because the key has to stay or
the model reads its own history as a call it never made. text for press_key,
key, hold_key and secondary_action is a name from a closed set the executor
publishes, so it is carried; that is one argument name meaning six things, and
only two of the six come from outside the model.

element_identity is added to the host-only set. The Computer Use tool's own
permissionArgs resolves the model's element_id against the live observation and
attaches its identity, and permissionArgs is what this projection now runs on,
so without that the model would read back a key it cannot send whose value came
off the accessibility tree.

For #1888 specifically: when the two are merged, computer-action-label.ts
should read window_id and element_id rather than windowId and elementId, since
the persisted args are now in the tool's dialect. Nothing on main reads the
persisted Computer Use args in the approval-summary dialect — the permission
prompt reads permissionArgs and the approval scope key is computed from the raw
call — so that renderer is the only reader affected.

Non-blocking finding: the title and body are rewritten. 0fcfb46 removed the
capability declarations, so the branch no longer does what it was named for;
what remains is the model-facing projection and the action-list parity guard,
and the description now says so and says what was dropped and why.

Rebased onto current main, cleanly. @maka/core and @maka/runtime suites pass,
npx biome check is clean on the touched files, and node scripts/check-console.mjs
passes.

[hqhq1025]

The record a model reads back of its own Computer Use call was the host's
approval projection, not the call. model-history.ts replays
event.content.args, and those args came from computerUseApprovalSummary,
which exists to decide and display a permission: it renames window_id to
windowId, adds approvalClass and rememberForTurnAllowed, and drops every
argument it does not need.

Measured on the real ToolRuntime, a model that sent

{"action":"press_key","app":"TextEdit","window_id":41,
"observation_id":"obs-7","element_id":"e12","text":"cmd+s"}

read back

{"action":"press_key","approvalClass":"keyboard_mutation",
"rememberForTurnAllowed":true,"app":"TextEdit","windowId":41,
"observationId":"obs-7"}

— a key the tool rejects, two fields it never sent, no element, and a
press_key with no key. A model imitates the shape it is shown, so it went on
calling it that way; a real desktop run failed six of eleven calls on shapes
copied from its own history.

This adds computerUseModelCallArgs: the same privacy rule, in the names the
tool accepts, and wires it at tool-runtime.ts, which is the line every
shipping backend goes through. The permission prompt still reads
permissionArgs and the approval scope key is still computed from the raw
call, so only what is written down changes.

What now crosses the privacy boundary

computer-use-privacy-boundary.test.ts asserted this line before this PR, and
it is updated in place rather than around, so the change is visible in the
diff. Two things cross that did not:

• element_id — an index the model chose into an observation it had already
  read (e12). Admitted only when it is a stable identifier, so an
  accessibility label arriving under that key is dropped rather than persisted.
  Without it, ten element actions in a turn are indistinguishable.
• coordinate, start_coordinate, region — geometry the model wrote into
  the call itself. Integers only, so a mistyped value still degrades to a
  shape. A coordinate is not read off the screen; withholding it leaves a model
  that clicked a point and missed unable to see that it had already tried that
  point.

What still does not cross: the value of text for type and select_text,
the value of set_value, and every other argument whose value is screen
content or something a person asked to have typed. Those keep their key and
lose their value to <text> — the key has to stay, or the model reads its own
history as a call it never made. text for press_key, key, hold_key and
secondary_action is a name from a closed set the executor publishes, so it is
carried: one argument name meaning six things, and only two of the six come
from outside the model.

element_identity joins approvalClass and rememberForTurnAllowed as
host-only. The Computer Use tool's own permissionArgs resolves the model's
element_id against the live observation and attaches it, and permissionArgs
is what this projection runs on.

Also here

COMPUTER_USE_SEMANTIC_ACTIONS replaces a hand-written action list that had
already drifted: window_action was added to the strict union and not to the
list, so every window move, resize and minimise would have summarised as
unknown — in the approval a person reads, and in the record the model reads
back. computer-use-schema-parity.test.ts now compares the two in both
directions.

Relationship to #1888

#1888 reached the same conclusion from the renderer's side and carried
elementId in the approval summary so its labels could tell two element rows
apart. That intent is subsumed here: element_id is carried, in the tool's own
casing. When the two are merged, #1888's computer-action-label.ts should read
window_id and element_id rather than windowId and elementId, and the
elementId case it added to computer-use-privacy-boundary.test.ts is covered
by the projection assertion in this branch.

Not here any more

The executor capability declarations this PR was originally titled for were
removed in 0fcfb46: nothing produced them, so they were a type surface with
no writer. The title and this description are rewritten to match what the
branch actually does.

Verification

The new assertion is on the tool_start event, not on the projection function.
Reverted to computerUseApprovalSummary at tool-runtime.ts and rebuilt, it
fails with exactly the diff quoted above; restored, it passes. A test that
calls computerUseModelCallArgs directly stays green either way, which is how
this survived being fixed once already in PiAgentBackend — a backend the
desktop app never instantiates.

@maka/core and @maka/runtime suites pass; npx biome check clean on the
touched files; node scripts/check-console.mjs passes. Rebased onto current
main, cleanly.

[hqhq1025]

Pushed fixes for all six findings. The claim in the PR body that nothing behaves differently was wrong, and finding 1 was the reason.

Finding 1, resolution: I scoped the constant to what main's schema accepts rather than stacking the PR on the executor branch. Verified first — main's wire enum at computer-use-tools.ts is list_apps, observe, click_element, set_value, select_text, secondary_action, press_key plus CU_ACTION_TYPES, and none of launch_app, scroll_element, element_sequence or window_action is in it. The four names went into APPROVAL_ACTIONS through COMPUTER_USE_SEMANTIC_ACTIONS, so computerUseApprovalSummary flipped knownAction to true for calls the SDK rejects before the tool runs, and rememberForTurnAllowed could evaluate true for the two that also joined SEMANTIC_ACTIONS. I chose scoping over stacking for two reasons. The constant's stated purpose is to be held against the tool schema, so declaring names the schema does not have is the same drift it exists to prevent, only in the direction nothing was checking. And stacking would make the PR unmergeable until the executor lands, which delays the parts that are correct today. The executor's vocabulary belongs on the branch that also ships the executor.

Finding 2: the promised file did not exist, but a guard did — computer-use-schema-parity.test.ts, added in #1870 after this branch was cut. It only walks from the schemas to the catalog, which catches a missing name and not an extra one, so the widening in finding 1 would have passed it. I added the reverse comparison to that file rather than creating the second one the comment named, and corrected the comment to point at the real file. Negative control: reintroducing the four names turns the new check red and it names all four. There is also an in-file control that runs the same comparator over a fixed catalog, so it keeps proving the comparator can return something on the day the real catalog is correct.

Finding 3: confirmed. Only COMPUTER_USE_SEMANTIC_ACTIONS was exported, so computerUseModelCallArgs was unreachable from @maka/runtime and the whole headline fix was dead code while the harmful widening was the only part that shipped. The five missing symbols are exported now, and the projection is wired into projectPiToolArgs in pi-agent-backend.ts, which writes the persisted tool_call message and the tool_start event. Negative control: reverting that one line turns the pi-agent-backend projection test red with the approval dialect back in the diff.

Finding 4: confirmed and dropped rather than wired. ComputerUseSettings appears in none of AppSettings, UpdateAppSettingsInput, the defaults, the merge or the normalize pass, unlike every peer settings module, and select-backend.ts assembles the CU tools with no enable check anywhere. A type that says enabled: false while the shipped app always has it on is worse than no type. Wiring a real switch needs a UI and a migration and does not belong under a types commit.

Finding 5: confirmed, and it is exactly as described. text is six arguments under one name — the key for press_key, key and hold_key, the element action name for secondary_action, a screen substring for select_text, typed content for type. MODEL_CALL_PLAIN_VALUES is now a map from action to the argument names that are plain for that action. An action the tool does not accept has no entry, so it falls through to shapes rather than to whichever set was used last. Negative control: reverting to the name-keyed set turns two tests red, showing press_key coming back as text: .

Finding 6, partially rejected with evidence. dispatch_refused is gone. It is not a declaration — COMPUTER_USE_ERROR_CODES is a runtime value feeding isComputerUseErrorCode, which decides at cua-driver-result.ts:88 whether a raw string from the driver process is trusted or replaced with capture_failed. Widening that with no producer is a live change. The other five named items are different in kind. messageIsAppTextFree, truncated, actions, subrole and placeholder are optional fields on TypeScript interfaces with no runtime effect, and they are not distinguishable from about ten other unproduced declarations in the same diff that the review accepted — focused, appAlias, obscuringRects, menu, query, CuLaunchedApp, scroll_element, window_action, launchApp. Dropping the named five and keeping those would be arbitrary; dropping all of them empties the branch of its purpose. Declaring the shape an executor returns is what this branch is for, so they stay, and the absent-means-withheld polarity on messageIsAppTextFree is kept as suggested.

Also rebased onto current main, which the branch was one commit behind — the missing commit was #1870, the parity test finding 2 turns out to depend on.

Test delta, measured against a baseline taken on clean origin/main on the same machine. This machine's Node has no node:sqlite, so @maka/runtime carries 64 pre-existing failing test names there. After the change: 2722 tests, zero new failures and zero fixed against that set. @maka/core goes 703/703 to 710/710, the seven new ones being the model-call projection tests. biome check clean on the six touched files, check-console passes.

[hqhq1025]

Second-round review addressed. Two findings fixed, one dropped after checking, one scope decision.

Coordinates are back. The doc said typed text, written values and coordinates are screen-derived and stay out, and that is false for the third one: a coordinate is the model's own output, four digits it chose and sent. Reduced to <point>, a model that clicked [412, 88] and missed could not tell whether it had already tried that point, which is the repeated-call shape this projection exists to make visible. coordinate, start_coordinate and region now come back whole when they are integers and still degrade to a shape when they are not, so a malformed argument does not become a leak channel.

The out-of-enum action is reported as sent. On the AI SDK path the question is moot — a schema-rejected call never produces a tool-call part, so settleToolCall is never reached and no tool_start is emitted. But this projection's only consumer is the Pi backend, where tool_start arrives as a transport frame that Maka does not validate, so the case is live there. It is also wrong in principle: this record is the model's own arguments, and the action is one of them. Collapsing an unrecognised name is computerUseApprovalSummary's job, where knownAction decides what a person is asked to allow; a test now pins that the two functions disagree on purpose. The action is bounded and redacted like every other model-supplied string.

The declared-and-unconsumed set is dropped. launchApp, CuLaunchedApp, truncated, actions, subrole, placeholder, focused, menu, query, appAlias, obscuringRects, targetWindowId, targetStacking, messageIsAppTextFree, and the scroll_element and window_action members of CuSemanticAction — zero producers and zero consumers, confirmed by grep across packages and apps. The reason is the parity guard's own header: window_action sat in the strict union and not on the wire, was unreachable from the day it shipped, and nothing failed, because a declaration with no producer has nothing to check it. This branch was putting window_action back into that state with scroll_element beside it. computer-use-types.ts is now byte-identical to main; the additions come with the executor that produces them, where a guard can assert they arrive. The PR body has been rewritten so it no longer claims them.

What is left is what has a consumer: COMPUTER_USE_SEMANTIC_ACTIONS with the two-way parity check, and computerUseModelCallArgs wired into the Pi backend.

Negative controls, run rather than asserted. Reverting the geometry branch turned the coordinate tests red on coordinate: '<point>' against [412, 88]; restoring the APPROVAL_ACTIONS gate on action turned the third red on unknown against element_sequence, and the Pi backend's own projection test with it. Both back to green after restoring.

One thing I did not change, because it is outside this branch: tool-runtime.ts:776 still writes computerUseApprovalSummary(permissionArgs) into both the tool_start event and the persisted tool_call message on the AI SDK path. That is the same defect this PR fixes, on the main backend rather than the Pi one. It needs its own change, since the same value also feeds describeToolIntent, the durable args hash and the approval record.

Test delta against a clean rebuild of main on this machine: none in packages/core or the Computer Use tests. The rest of the run is shell, filesystem and host-process timing under load 40 on this box; each one passes when its file is run alone.

[hqhq1025]

Blocking finding addressed: the fix is moved to the path the shipping app runs.

It was wired into PiAgentBackend, which the desktop app never instantiates.
boot.ts registers only ai-sdk and fake; the pi backend is reachable only from
harbor-cell.ts behind MAKA_PI_*, driving an external CLI, and it does not
construct a ToolRuntime at all. tool-runtime.ts had a zero-byte diff, so on the
shipping path nothing changed. Measured on the real ToolRuntime, a model that
sent action press_key with app, window_id 41, observation_id obs-7, element_id
e12 and text cmd+s read back action, approvalClass, rememberForTurnAllowed,
app, windowId 41, observationId — a key the tool rejects, two fields it never
sent, no element, and a press_key with no key. That is now the one line the PR
changes in production.

The new assertion is on the tool_start event, which is what model-history.ts
replays, rather than on the projection function. Reverted to
computerUseApprovalSummary and rebuilt, it fails with exactly the diff above;
restored, it passes. A test calling computerUseModelCallArgs directly stays
green either way, which is how this survived being fixed once already.

On the coupling with #1888 and the privacy boundary, since the description
asked that it not be resolved silently.

computer-use-privacy-boundary.test.ts is not new to #1888; it has asserted this
line since #1581, and #1888 added an elementId case to it. Both PRs are
therefore changing the same invariant, and this one changes it in place rather
than around it, so what crosses is visible in the diff and is spelled out in
the file, the commit message and the PR body.

Two things now cross. element_id, which is an index the model chose into an
observation it had already read, admitted only when it is a stable identifier
so an accessibility label arriving under that key is dropped — this is exactly
what #1888 wanted and it is subsumed here, in the tool's own casing.
coordinate, start_coordinate and region, which are geometry the model wrote
into the call itself, integers only so a mistyped value still degrades to a
shape.

The argument for carrying coordinates is that they are the model's own output,
already present in the assistant turn that produced them, and that withholding
them leaves a model that clicked a point and missed unable to see that it had
already tried that point. The argument against, that for set_value and type
these are what the user was having typed on their behalf, does not apply to
coordinates: it applies to text and value, and those still do not cross. They
keep their key and lose their value to , because the key has to stay or
the model reads its own history as a call it never made. text for press_key,
key, hold_key and secondary_action is a name from a closed set the executor
publishes, so it is carried; that is one argument name meaning six things, and
only two of the six come from outside the model.

element_identity is added to the host-only set. The Computer Use tool's own
permissionArgs resolves the model's element_id against the live observation and
attaches its identity, and permissionArgs is what this projection now runs on,
so without that the model would read back a key it cannot send whose value came
off the accessibility tree.

For #1888 specifically: when the two are merged, computer-action-label.ts
should read window_id and element_id rather than windowId and elementId, since
the persisted args are now in the tool's dialect. Nothing on main reads the
persisted Computer Use args in the approval-summary dialect — the permission
prompt reads permissionArgs and the approval scope key is computed from the raw
call — so that renderer is the only reader affected.

Non-blocking finding: the title and body are rewritten. 0fcfb46 removed the
capability declarations, so the branch no longer does what it was named for;
what remains is the model-facing projection and the action-list parity guard,
and the description now says so and says what was dropped and why.

Rebased onto current main, cleanly. @maka/core and @maka/runtime suites pass,
npx biome check is clean on the touched files, and node scripts/check-console.mjs
passes.

[hqhq1025]

The record a model reads back of its own Computer Use call was the host's
approval projection, not the call. model-history.ts replays
event.content.args, and those args came from computerUseApprovalSummary,
which exists to decide and display a permission: it renames window_id to
windowId, adds approvalClass and rememberForTurnAllowed, and drops every
argument it does not need.

Measured on the real ToolRuntime, a model that sent

{"action":"press_key","app":"TextEdit","window_id":41,
"observation_id":"obs-7","element_id":"e12","text":"cmd+s"}

read back

{"action":"press_key","approvalClass":"keyboard_mutation",
"rememberForTurnAllowed":true,"app":"TextEdit","windowId":41,
"observationId":"obs-7"}

— a key the tool rejects, two fields it never sent, no element, and a
press_key with no key. A model imitates the shape it is shown, so it went on
calling it that way; a real desktop run failed six of eleven calls on shapes
copied from its own history.

This adds computerUseModelCallArgs: the same privacy rule, in the names the
tool accepts, and wires it at tool-runtime.ts, which is the line every
shipping backend goes through. The permission prompt still reads
permissionArgs and the approval scope key is still computed from the raw
call, so only what is written down changes.

What now crosses the privacy boundary

computer-use-privacy-boundary.test.ts asserted this line before this PR, and
it is updated in place rather than around, so the change is visible in the
diff. Two things cross that did not:

• element_id — an index the model chose into an observation it had already
  read (e12). Admitted only when it is a stable identifier, so an
  accessibility label arriving under that key is dropped rather than persisted.
  Without it, ten element actions in a turn are indistinguishable.
• coordinate, start_coordinate, region — geometry the model wrote into
  the call itself. Integers only, so a mistyped value still degrades to a
  shape. A coordinate is not read off the screen; withholding it leaves a model
  that clicked a point and missed unable to see that it had already tried that
  point.

What still does not cross: the value of text for type and select_text,
the value of set_value, and every other argument whose value is screen
content or something a person asked to have typed. Those keep their key and
lose their value to <text> — the key has to stay, or the model reads its own
history as a call it never made. text for press_key, key, hold_key and
secondary_action is a name from a closed set the executor publishes, so it is
carried: one argument name meaning six things, and only two of the six come
from outside the model.

element_identity joins approvalClass and rememberForTurnAllowed as
host-only. The Computer Use tool's own permissionArgs resolves the model's
element_id against the live observation and attaches it, and permissionArgs
is what this projection runs on.

Also here

COMPUTER_USE_SEMANTIC_ACTIONS replaces a hand-written action list that had
already drifted: window_action was added to the strict union and not to the
list, so every window move, resize and minimise would have summarised as
unknown — in the approval a person reads, and in the record the model reads
back. computer-use-schema-parity.test.ts now compares the two in both
directions.

Relationship to #1888

#1888 reached the same conclusion from the renderer's side and carried
elementId in the approval summary so its labels could tell two element rows
apart. That intent is subsumed here: element_id is carried, in the tool's own
casing. When the two are merged, #1888's computer-action-label.ts should read
window_id and element_id rather than windowId and elementId, and the
elementId case it added to computer-use-privacy-boundary.test.ts is covered
by the projection assertion in this branch.

Not here any more

The executor capability declarations this PR was originally titled for were
removed in 0fcfb46: nothing produced them, so they were a type surface with
no writer. The title and this description are rewritten to match what the
branch actually does.

Verification

The new assertion is on the tool_start event, not on the projection function.
Reverted to computerUseApprovalSummary at tool-runtime.ts and rebuilt, it
fails with exactly the diff quoted above; restored, it passes. A test that
calls computerUseModelCallArgs directly stays green either way, which is how
this survived being fixed once already in PiAgentBackend — a backend the
desktop app never instantiates.

@maka/core and @maka/runtime suites pass; npx biome check clean on the
touched files; node scripts/check-console.mjs passes. Rebased onto current
main, cleanly.

[hqhq1025]

Pushed fixes for all six findings. The claim in the PR body that nothing behaves differently was wrong, and finding 1 was the reason.

Finding 1, resolution: I scoped the constant to what main's schema accepts rather than stacking the PR on the executor branch. Verified first — main's wire enum at computer-use-tools.ts is list_apps, observe, click_element, set_value, select_text, secondary_action, press_key plus CU_ACTION_TYPES, and none of launch_app, scroll_element, element_sequence or window_action is in it. The four names went into APPROVAL_ACTIONS through COMPUTER_USE_SEMANTIC_ACTIONS, so computerUseApprovalSummary flipped knownAction to true for calls the SDK rejects before the tool runs, and rememberForTurnAllowed could evaluate true for the two that also joined SEMANTIC_ACTIONS. I chose scoping over stacking for two reasons. The constant's stated purpose is to be held against the tool schema, so declaring names the schema does not have is the same drift it exists to prevent, only in the direction nothing was checking. And stacking would make the PR unmergeable until the executor lands, which delays the parts that are correct today. The executor's vocabulary belongs on the branch that also ships the executor.

Finding 2: the promised file did not exist, but a guard did — computer-use-schema-parity.test.ts, added in #1870 after this branch was cut. It only walks from the schemas to the catalog, which catches a missing name and not an extra one, so the widening in finding 1 would have passed it. I added the reverse comparison to that file rather than creating the second one the comment named, and corrected the comment to point at the real file. Negative control: reintroducing the four names turns the new check red and it names all four. There is also an in-file control that runs the same comparator over a fixed catalog, so it keeps proving the comparator can return something on the day the real catalog is correct.

Finding 3: confirmed. Only COMPUTER_USE_SEMANTIC_ACTIONS was exported, so computerUseModelCallArgs was unreachable from @maka/runtime and the whole headline fix was dead code while the harmful widening was the only part that shipped. The five missing symbols are exported now, and the projection is wired into projectPiToolArgs in pi-agent-backend.ts, which writes the persisted tool_call message and the tool_start event. Negative control: reverting that one line turns the pi-agent-backend projection test red with the approval dialect back in the diff.

Finding 4: confirmed and dropped rather than wired. ComputerUseSettings appears in none of AppSettings, UpdateAppSettingsInput, the defaults, the merge or the normalize pass, unlike every peer settings module, and select-backend.ts assembles the CU tools with no enable check anywhere. A type that says enabled: false while the shipped app always has it on is worse than no type. Wiring a real switch needs a UI and a migration and does not belong under a types commit.

Finding 5: confirmed, and it is exactly as described. text is six arguments under one name — the key for press_key, key and hold_key, the element action name for secondary_action, a screen substring for select_text, typed content for type. MODEL_CALL_PLAIN_VALUES is now a map from action to the argument names that are plain for that action. An action the tool does not accept has no entry, so it falls through to shapes rather than to whichever set was used last. Negative control: reverting to the name-keyed set turns two tests red, showing press_key coming back as text: .

Finding 6, partially rejected with evidence. dispatch_refused is gone. It is not a declaration — COMPUTER_USE_ERROR_CODES is a runtime value feeding isComputerUseErrorCode, which decides at cua-driver-result.ts:88 whether a raw string from the driver process is trusted or replaced with capture_failed. Widening that with no producer is a live change. The other five named items are different in kind. messageIsAppTextFree, truncated, actions, subrole and placeholder are optional fields on TypeScript interfaces with no runtime effect, and they are not distinguishable from about ten other unproduced declarations in the same diff that the review accepted — focused, appAlias, obscuringRects, menu, query, CuLaunchedApp, scroll_element, window_action, launchApp. Dropping the named five and keeping those would be arbitrary; dropping all of them empties the branch of its purpose. Declaring the shape an executor returns is what this branch is for, so they stay, and the absent-means-withheld polarity on messageIsAppTextFree is kept as suggested.

Also rebased onto current main, which the branch was one commit behind — the missing commit was #1870, the parity test finding 2 turns out to depend on.

Test delta, measured against a baseline taken on clean origin/main on the same machine. This machine's Node has no node:sqlite, so @maka/runtime carries 64 pre-existing failing test names there. After the change: 2722 tests, zero new failures and zero fixed against that set. @maka/core goes 703/703 to 710/710, the seven new ones being the model-call projection tests. biome check clean on the six touched files, check-console passes.

[hqhq1025]

Second-round review addressed. Two findings fixed, one dropped after checking, one scope decision.

Coordinates are back. The doc said typed text, written values and coordinates are screen-derived and stay out, and that is false for the third one: a coordinate is the model's own output, four digits it chose and sent. Reduced to <point>, a model that clicked [412, 88] and missed could not tell whether it had already tried that point, which is the repeated-call shape this projection exists to make visible. coordinate, start_coordinate and region now come back whole when they are integers and still degrade to a shape when they are not, so a malformed argument does not become a leak channel.

The out-of-enum action is reported as sent. On the AI SDK path the question is moot — a schema-rejected call never produces a tool-call part, so settleToolCall is never reached and no tool_start is emitted. But this projection's only consumer is the Pi backend, where tool_start arrives as a transport frame that Maka does not validate, so the case is live there. It is also wrong in principle: this record is the model's own arguments, and the action is one of them. Collapsing an unrecognised name is computerUseApprovalSummary's job, where knownAction decides what a person is asked to allow; a test now pins that the two functions disagree on purpose. The action is bounded and redacted like every other model-supplied string.

The declared-and-unconsumed set is dropped. launchApp, CuLaunchedApp, truncated, actions, subrole, placeholder, focused, menu, query, appAlias, obscuringRects, targetWindowId, targetStacking, messageIsAppTextFree, and the scroll_element and window_action members of CuSemanticAction — zero producers and zero consumers, confirmed by grep across packages and apps. The reason is the parity guard's own header: window_action sat in the strict union and not on the wire, was unreachable from the day it shipped, and nothing failed, because a declaration with no producer has nothing to check it. This branch was putting window_action back into that state with scroll_element beside it. computer-use-types.ts is now byte-identical to main; the additions come with the executor that produces them, where a guard can assert they arrive. The PR body has been rewritten so it no longer claims them.

What is left is what has a consumer: COMPUTER_USE_SEMANTIC_ACTIONS with the two-way parity check, and computerUseModelCallArgs wired into the Pi backend.

Negative controls, run rather than asserted. Reverting the geometry branch turned the coordinate tests red on coordinate: '<point>' against [412, 88]; restoring the APPROVAL_ACTIONS gate on action turned the third red on unknown against element_sequence, and the Pi backend's own projection test with it. Both back to green after restoring.

One thing I did not change, because it is outside this branch: tool-runtime.ts:776 still writes computerUseApprovalSummary(permissionArgs) into both the tool_start event and the persisted tool_call message on the AI SDK path. That is the same defect this PR fixes, on the main backend rather than the Pi one. It needs its own change, since the same value also feeds describeToolIntent, the durable args hash and the approval record.

Test delta against a clean rebuild of main on this machine: none in packages/core or the Computer Use tests. The rest of the run is shell, filesystem and host-process timing under load 40 on this box; each one passes when its file is run alone.

[hqhq1025]

Blocking finding addressed: the fix is moved to the path the shipping app runs.

It was wired into PiAgentBackend, which the desktop app never instantiates.
boot.ts registers only ai-sdk and fake; the pi backend is reachable only from
harbor-cell.ts behind MAKA_PI_*, driving an external CLI, and it does not
construct a ToolRuntime at all. tool-runtime.ts had a zero-byte diff, so on the
shipping path nothing changed. Measured on the real ToolRuntime, a model that
sent action press_key with app, window_id 41, observation_id obs-7, element_id
e12 and text cmd+s read back action, approvalClass, rememberForTurnAllowed,
app, windowId 41, observationId — a key the tool rejects, two fields it never
sent, no element, and a press_key with no key. That is now the one line the PR
changes in production.

The new assertion is on the tool_start event, which is what model-history.ts
replays, rather than on the projection function. Reverted to
computerUseApprovalSummary and rebuilt, it fails with exactly the diff above;
restored, it passes. A test calling computerUseModelCallArgs directly stays
green either way, which is how this survived being fixed once already.

On the coupling with #1888 and the privacy boundary, since the description
asked that it not be resolved silently.

computer-use-privacy-boundary.test.ts is not new to #1888; it has asserted this
line since #1581, and #1888 added an elementId case to it. Both PRs are
therefore changing the same invariant, and this one changes it in place rather
than around it, so what crosses is visible in the diff and is spelled out in
the file, the commit message and the PR body.

Two things now cross. element_id, which is an index the model chose into an
observation it had already read, admitted only when it is a stable identifier
so an accessibility label arriving under that key is dropped — this is exactly
what #1888 wanted and it is subsumed here, in the tool's own casing.
coordinate, start_coordinate and region, which are geometry the model wrote
into the call itself, integers only so a mistyped value still degrades to a
shape.

The argument for carrying coordinates is that they are the model's own output,
already present in the assistant turn that produced them, and that withholding
them leaves a model that clicked a point and missed unable to see that it had
already tried that point. The argument against, that for set_value and type
these are what the user was having typed on their behalf, does not apply to
coordinates: it applies to text and value, and those still do not cross. They
keep their key and lose their value to , because the key has to stay or
the model reads its own history as a call it never made. text for press_key,
key, hold_key and secondary_action is a name from a closed set the executor
publishes, so it is carried; that is one argument name meaning six things, and
only two of the six come from outside the model.

element_identity is added to the host-only set. The Computer Use tool's own
permissionArgs resolves the model's element_id against the live observation and
attaches its identity, and permissionArgs is what this projection now runs on,
so without that the model would read back a key it cannot send whose value came
off the accessibility tree.

For #1888 specifically: when the two are merged, computer-action-label.ts
should read window_id and element_id rather than windowId and elementId, since
the persisted args are now in the tool's dialect. Nothing on main reads the
persisted Computer Use args in the approval-summary dialect — the permission
prompt reads permissionArgs and the approval scope key is computed from the raw
call — so that renderer is the only reader affected.

Non-blocking finding: the title and body are rewritten. 0fcfb46 removed the
capability declarations, so the branch no longer does what it was named for;
what remains is the model-facing projection and the action-list parity guard,
and the description now says so and says what was dropped and why.

Rebased onto current main, cleanly. @maka/core and @maka/runtime suites pass,
npx biome check is clean on the touched files, and node scripts/check-console.mjs
passes.

[hqhq1025]

The record a model reads back of its own Computer Use call was the host's
approval projection, not the call. model-history.ts replays
event.content.args, and those args came from computerUseApprovalSummary,
which exists to decide and display a permission: it renames window_id to
windowId, adds approvalClass and rememberForTurnAllowed, and drops every
argument it does not need.

Measured on the real ToolRuntime, a model that sent

{"action":"press_key","app":"TextEdit","window_id":41,
"observation_id":"obs-7","element_id":"e12","text":"cmd+s"}

read back

{"action":"press_key","approvalClass":"keyboard_mutation",
"rememberForTurnAllowed":true,"app":"TextEdit","windowId":41,
"observationId":"obs-7"}

— a key the tool rejects, two fields it never sent, no element, and a
press_key with no key. A model imitates the shape it is shown, so it went on
calling it that way; a real desktop run failed six of eleven calls on shapes
copied from its own history.

This adds computerUseModelCallArgs: the same privacy rule, in the names the
tool accepts, and wires it at tool-runtime.ts, which is the line every
shipping backend goes through. The permission prompt still reads
permissionArgs and the approval scope key is still computed from the raw
call, so only what is written down changes.

What now crosses the privacy boundary

computer-use-privacy-boundary.test.ts asserted this line before this PR, and
it is updated in place rather than around, so the change is visible in the
diff. Two things cross that did not:

• element_id — an index the model chose into an observation it had already
  read (e12). Admitted only when it is a stable identifier, so an
  accessibility label arriving under that key is dropped rather than persisted.
  Without it, ten element actions in a turn are indistinguishable.
• coordinate, start_coordinate, region — geometry the model wrote into
  the call itself. Integers only, so a mistyped value still degrades to a
  shape. A coordinate is not read off the screen; withholding it leaves a model
  that clicked a point and missed unable to see that it had already tried that
  point.

What still does not cross: the value of text for type and select_text,
the value of set_value, and every other argument whose value is screen
content or something a person asked to have typed. Those keep their key and
lose their value to <text> — the key has to stay, or the model reads its own
history as a call it never made. text for press_key, key, hold_key and
secondary_action is a name from a closed set the executor publishes, so it is
carried: one argument name meaning six things, and only two of the six come
from outside the model.

element_identity joins approvalClass and rememberForTurnAllowed as
host-only. The Computer Use tool's own permissionArgs resolves the model's
element_id against the live observation and attaches it, and permissionArgs
is what this projection runs on.

Also here

COMPUTER_USE_SEMANTIC_ACTIONS replaces a hand-written action list that had
already drifted: window_action was added to the strict union and not to the
list, so every window move, resize and minimise would have summarised as
unknown — in the approval a person reads, and in the record the model reads
back. computer-use-schema-parity.test.ts now compares the two in both
directions.

Relationship to #1888

#1888 reached the same conclusion from the renderer's side and carried
elementId in the approval summary so its labels could tell two element rows
apart. That intent is subsumed here: element_id is carried, in the tool's own
casing. When the two are merged, #1888's computer-action-label.ts should read
window_id and element_id rather than windowId and elementId, and the
elementId case it added to computer-use-privacy-boundary.test.ts is covered
by the projection assertion in this branch.

Not here any more

The executor capability declarations this PR was originally titled for were
removed in 0fcfb46: nothing produced them, so they were a type surface with
no writer. The title and this description are rewritten to match what the
branch actually does.

Verification

The new assertion is on the tool_start event, not on the projection function.
Reverted to computerUseApprovalSummary at tool-runtime.ts and rebuilt, it
fails with exactly the diff quoted above; restored, it passes. A test that
calls computerUseModelCallArgs directly stays green either way, which is how
this survived being fixed once already in PiAgentBackend — a backend the
desktop app never instantiates.

@maka/core and @maka/runtime suites pass; npx biome check clean on the
touched files; node scripts/check-console.mjs passes. Rebased onto current
main, cleanly.

[hqhq1025]

Pushed fixes for all six findings. The claim in the PR body that nothing behaves differently was wrong, and finding 1 was the reason.

Finding 1, resolution: I scoped the constant to what main's schema accepts rather than stacking the PR on the executor branch. Verified first — main's wire enum at computer-use-tools.ts is list_apps, observe, click_element, set_value, select_text, secondary_action, press_key plus CU_ACTION_TYPES, and none of launch_app, scroll_element, element_sequence or window_action is in it. The four names went into APPROVAL_ACTIONS through COMPUTER_USE_SEMANTIC_ACTIONS, so computerUseApprovalSummary flipped knownAction to true for calls the SDK rejects before the tool runs, and rememberForTurnAllowed could evaluate true for the two that also joined SEMANTIC_ACTIONS. I chose scoping over stacking for two reasons. The constant's stated purpose is to be held against the tool schema, so declaring names the schema does not have is the same drift it exists to prevent, only in the direction nothing was checking. And stacking would make the PR unmergeable until the executor lands, which delays the parts that are correct today. The executor's vocabulary belongs on the branch that also ships the executor.

Finding 2: the promised file did not exist, but a guard did — computer-use-schema-parity.test.ts, added in #1870 after this branch was cut. It only walks from the schemas to the catalog, which catches a missing name and not an extra one, so the widening in finding 1 would have passed it. I added the reverse comparison to that file rather than creating the second one the comment named, and corrected the comment to point at the real file. Negative control: reintroducing the four names turns the new check red and it names all four. There is also an in-file control that runs the same comparator over a fixed catalog, so it keeps proving the comparator can return something on the day the real catalog is correct.

Finding 3: confirmed. Only COMPUTER_USE_SEMANTIC_ACTIONS was exported, so computerUseModelCallArgs was unreachable from @maka/runtime and the whole headline fix was dead code while the harmful widening was the only part that shipped. The five missing symbols are exported now, and the projection is wired into projectPiToolArgs in pi-agent-backend.ts, which writes the persisted tool_call message and the tool_start event. Negative control: reverting that one line turns the pi-agent-backend projection test red with the approval dialect back in the diff.

Finding 4: confirmed and dropped rather than wired. ComputerUseSettings appears in none of AppSettings, UpdateAppSettingsInput, the defaults, the merge or the normalize pass, unlike every peer settings module, and select-backend.ts assembles the CU tools with no enable check anywhere. A type that says enabled: false while the shipped app always has it on is worse than no type. Wiring a real switch needs a UI and a migration and does not belong under a types commit.

Finding 5: confirmed, and it is exactly as described. text is six arguments under one name — the key for press_key, key and hold_key, the element action name for secondary_action, a screen substring for select_text, typed content for type. MODEL_CALL_PLAIN_VALUES is now a map from action to the argument names that are plain for that action. An action the tool does not accept has no entry, so it falls through to shapes rather than to whichever set was used last. Negative control: reverting to the name-keyed set turns two tests red, showing press_key coming back as text: .

Finding 6, partially rejected with evidence. dispatch_refused is gone. It is not a declaration — COMPUTER_USE_ERROR_CODES is a runtime value feeding isComputerUseErrorCode, which decides at cua-driver-result.ts:88 whether a raw string from the driver process is trusted or replaced with capture_failed. Widening that with no producer is a live change. The other five named items are different in kind. messageIsAppTextFree, truncated, actions, subrole and placeholder are optional fields on TypeScript interfaces with no runtime effect, and they are not distinguishable from about ten other unproduced declarations in the same diff that the review accepted — focused, appAlias, obscuringRects, menu, query, CuLaunchedApp, scroll_element, window_action, launchApp. Dropping the named five and keeping those would be arbitrary; dropping all of them empties the branch of its purpose. Declaring the shape an executor returns is what this branch is for, so they stay, and the absent-means-withheld polarity on messageIsAppTextFree is kept as suggested.

Also rebased onto current main, which the branch was one commit behind — the missing commit was #1870, the parity test finding 2 turns out to depend on.

Test delta, measured against a baseline taken on clean origin/main on the same machine. This machine's Node has no node:sqlite, so @maka/runtime carries 64 pre-existing failing test names there. After the change: 2722 tests, zero new failures and zero fixed against that set. @maka/core goes 703/703 to 710/710, the seven new ones being the model-call projection tests. biome check clean on the six touched files, check-console passes.

[hqhq1025]

Second-round review addressed. Two findings fixed, one dropped after checking, one scope decision.

Coordinates are back. The doc said typed text, written values and coordinates are screen-derived and stay out, and that is false for the third one: a coordinate is the model's own output, four digits it chose and sent. Reduced to <point>, a model that clicked [412, 88] and missed could not tell whether it had already tried that point, which is the repeated-call shape this projection exists to make visible. coordinate, start_coordinate and region now come back whole when they are integers and still degrade to a shape when they are not, so a malformed argument does not become a leak channel.

The out-of-enum action is reported as sent. On the AI SDK path the question is moot — a schema-rejected call never produces a tool-call part, so settleToolCall is never reached and no tool_start is emitted. But this projection's only consumer is the Pi backend, where tool_start arrives as a transport frame that Maka does not validate, so the case is live there. It is also wrong in principle: this record is the model's own arguments, and the action is one of them. Collapsing an unrecognised name is computerUseApprovalSummary's job, where knownAction decides what a person is asked to allow; a test now pins that the two functions disagree on purpose. The action is bounded and redacted like every other model-supplied string.

The declared-and-unconsumed set is dropped. launchApp, CuLaunchedApp, truncated, actions, subrole, placeholder, focused, menu, query, appAlias, obscuringRects, targetWindowId, targetStacking, messageIsAppTextFree, and the scroll_element and window_action members of CuSemanticAction — zero producers and zero consumers, confirmed by grep across packages and apps. The reason is the parity guard's own header: window_action sat in the strict union and not on the wire, was unreachable from the day it shipped, and nothing failed, because a declaration with no producer has nothing to check it. This branch was putting window_action back into that state with scroll_element beside it. computer-use-types.ts is now byte-identical to main; the additions come with the executor that produces them, where a guard can assert they arrive. The PR body has been rewritten so it no longer claims them.

What is left is what has a consumer: COMPUTER_USE_SEMANTIC_ACTIONS with the two-way parity check, and computerUseModelCallArgs wired into the Pi backend.

Negative controls, run rather than asserted. Reverting the geometry branch turned the coordinate tests red on coordinate: '<point>' against [412, 88]; restoring the APPROVAL_ACTIONS gate on action turned the third red on unknown against element_sequence, and the Pi backend's own projection test with it. Both back to green after restoring.

One thing I did not change, because it is outside this branch: tool-runtime.ts:776 still writes computerUseApprovalSummary(permissionArgs) into both the tool_start event and the persisted tool_call message on the AI SDK path. That is the same defect this PR fixes, on the main backend rather than the Pi one. It needs its own change, since the same value also feeds describeToolIntent, the durable args hash and the approval record.

Test delta against a clean rebuild of main on this machine: none in packages/core or the Computer Use tests. The rest of the run is shell, filesystem and host-process timing under load 40 on this box; each one passes when its file is run alone.

[hqhq1025]

Blocking finding addressed: the fix is moved to the path the shipping app runs.

It was wired into PiAgentBackend, which the desktop app never instantiates.
boot.ts registers only ai-sdk and fake; the pi backend is reachable only from
harbor-cell.ts behind MAKA_PI_*, driving an external CLI, and it does not
construct a ToolRuntime at all. tool-runtime.ts had a zero-byte diff, so on the
shipping path nothing changed. Measured on the real ToolRuntime, a model that
sent action press_key with app, window_id 41, observation_id obs-7, element_id
e12 and text cmd+s read back action, approvalClass, rememberForTurnAllowed,
app, windowId 41, observationId — a key the tool rejects, two fields it never
sent, no element, and a press_key with no key. That is now the one line the PR
changes in production.

The new assertion is on the tool_start event, which is what model-history.ts
replays, rather than on the projection function. Reverted to
computerUseApprovalSummary and rebuilt, it fails with exactly the diff above;
restored, it passes. A test calling computerUseModelCallArgs directly stays
green either way, which is how this survived being fixed once already.

On the coupling with #1888 and the privacy boundary, since the description
asked that it not be resolved silently.

computer-use-privacy-boundary.test.ts is not new to #1888; it has asserted this
line since #1581, and #1888 added an elementId case to it. Both PRs are
therefore changing the same invariant, and this one changes it in place rather
than around it, so what crosses is visible in the diff and is spelled out in
the file, the commit message and the PR body.

Two things now cross. element_id, which is an index the model chose into an
observation it had already read, admitted only when it is a stable identifier
so an accessibility label arriving under that key is dropped — this is exactly
what #1888 wanted and it is subsumed here, in the tool's own casing.
coordinate, start_coordinate and region, which are geometry the model wrote
into the call itself, integers only so a mistyped value still degrades to a
shape.

The argument for carrying coordinates is that they are the model's own output,
already present in the assistant turn that produced them, and that withholding
them leaves a model that clicked a point and missed unable to see that it had
already tried that point. The argument against, that for set_value and type
these are what the user was having typed on their behalf, does not apply to
coordinates: it applies to text and value, and those still do not cross. They
keep their key and lose their value to , because the key has to stay or
the model reads its own history as a call it never made. text for press_key,
key, hold_key and secondary_action is a name from a closed set the executor
publishes, so it is carried; that is one argument name meaning six things, and
only two of the six come from outside the model.

element_identity is added to the host-only set. The Computer Use tool's own
permissionArgs resolves the model's element_id against the live observation and
attaches its identity, and permissionArgs is what this projection now runs on,
so without that the model would read back a key it cannot send whose value came
off the accessibility tree.

For #1888 specifically: when the two are merged, computer-action-label.ts
should read window_id and element_id rather than windowId and elementId, since
the persisted args are now in the tool's dialect. Nothing on main reads the
persisted Computer Use args in the approval-summary dialect — the permission
prompt reads permissionArgs and the approval scope key is computed from the raw
call — so that renderer is the only reader affected.

Non-blocking finding: the title and body are rewritten. 0fcfb46 removed the
capability declarations, so the branch no longer does what it was named for;
what remains is the model-facing projection and the action-list parity guard,
and the description now says so and says what was dropped and why.

Rebased onto current main, cleanly. @maka/core and @maka/runtime suites pass,
npx biome check is clean on the touched files, and node scripts/check-console.mjs
passes.

[hqhq1025]

The record a model reads back of its own Computer Use call was the host's
approval projection, not the call. model-history.ts replays
event.content.args, and those args came from computerUseApprovalSummary,
which exists to decide and display a permission: it renames window_id to
windowId, adds approvalClass and rememberForTurnAllowed, and drops every
argument it does not need.

Measured on the real ToolRuntime, a model that sent

{"action":"press_key","app":"TextEdit","window_id":41,
"observation_id":"obs-7","element_id":"e12","text":"cmd+s"}

read back

{"action":"press_key","approvalClass":"keyboard_mutation",
"rememberForTurnAllowed":true,"app":"TextEdit","windowId":41,
"observationId":"obs-7"}

— a key the tool rejects, two fields it never sent, no element, and a
press_key with no key. A model imitates the shape it is shown, so it went on
calling it that way; a real desktop run failed six of eleven calls on shapes
copied from its own history.

This adds computerUseModelCallArgs: the same privacy rule, in the names the
tool accepts, and wires it at tool-runtime.ts, which is the line every
shipping backend goes through. The permission prompt still reads
permissionArgs and the approval scope key is still computed from the raw
call, so only what is written down changes.

What now crosses the privacy boundary

computer-use-privacy-boundary.test.ts asserted this line before this PR, and
it is updated in place rather than around, so the change is visible in the
diff. Two things cross that did not:

• element_id — an index the model chose into an observation it had already
  read (e12). Admitted only when it is a stable identifier, so an
  accessibility label arriving under that key is dropped rather than persisted.
  Without it, ten element actions in a turn are indistinguishable.
• coordinate, start_coordinate, region — geometry the model wrote into
  the call itself. Integers only, so a mistyped value still degrades to a
  shape. A coordinate is not read off the screen; withholding it leaves a model
  that clicked a point and missed unable to see that it had already tried that
  point.

What still does not cross: the value of text for type and select_text,
the value of set_value, and every other argument whose value is screen
content or something a person asked to have typed. Those keep their key and
lose their value to <text> — the key has to stay, or the model reads its own
history as a call it never made. text for press_key, key, hold_key and
secondary_action is a name from a closed set the executor publishes, so it is
carried: one argument name meaning six things, and only two of the six come
from outside the model.

element_identity joins approvalClass and rememberForTurnAllowed as
host-only. The Computer Use tool's own permissionArgs resolves the model's
element_id against the live observation and attaches it, and permissionArgs
is what this projection runs on.

Also here

COMPUTER_USE_SEMANTIC_ACTIONS replaces a hand-written action list that had
already drifted: window_action was added to the strict union and not to the
list, so every window move, resize and minimise would have summarised as
unknown — in the approval a person reads, and in the record the model reads
back. computer-use-schema-parity.test.ts now compares the two in both
directions.

Relationship to #1888

#1888 reached the same conclusion from the renderer's side and carried
elementId in the approval summary so its labels could tell two element rows
apart. That intent is subsumed here: element_id is carried, in the tool's own
casing. When the two are merged, #1888's computer-action-label.ts should read
window_id and element_id rather than windowId and elementId, and the
elementId case it added to computer-use-privacy-boundary.test.ts is covered
by the projection assertion in this branch.

Not here any more

The executor capability declarations this PR was originally titled for were
removed in 0fcfb46: nothing produced them, so they were a type surface with
no writer. The title and this description are rewritten to match what the
branch actually does.

Verification

The new assertion is on the tool_start event, not on the projection function.
Reverted to computerUseApprovalSummary at tool-runtime.ts and rebuilt, it
fails with exactly the diff quoted above; restored, it passes. A test that
calls computerUseModelCallArgs directly stays green either way, which is how
this survived being fixed once already in PiAgentBackend — a backend the
desktop app never instantiates.

@maka/core and @maka/runtime suites pass; npx biome check clean on the
touched files; node scripts/check-console.mjs passes. Rebased onto current
main, cleanly.

[hqhq1025]

Pushed fixes for all six findings. The claim in the PR body that nothing behaves differently was wrong, and finding 1 was the reason.

Finding 1, resolution: I scoped the constant to what main's schema accepts rather than stacking the PR on the executor branch. Verified first — main's wire enum at computer-use-tools.ts is list_apps, observe, click_element, set_value, select_text, secondary_action, press_key plus CU_ACTION_TYPES, and none of launch_app, scroll_element, element_sequence or window_action is in it. The four names went into APPROVAL_ACTIONS through COMPUTER_USE_SEMANTIC_ACTIONS, so computerUseApprovalSummary flipped knownAction to true for calls the SDK rejects before the tool runs, and rememberForTurnAllowed could evaluate true for the two that also joined SEMANTIC_ACTIONS. I chose scoping over stacking for two reasons. The constant's stated purpose is to be held against the tool schema, so declaring names the schema does not have is the same drift it exists to prevent, only in the direction nothing was checking. And stacking would make the PR unmergeable until the executor lands, which delays the parts that are correct today. The executor's vocabulary belongs on the branch that also ships the executor.

Finding 2: the promised file did not exist, but a guard did — computer-use-schema-parity.test.ts, added in #1870 after this branch was cut. It only walks from the schemas to the catalog, which catches a missing name and not an extra one, so the widening in finding 1 would have passed it. I added the reverse comparison to that file rather than creating the second one the comment named, and corrected the comment to point at the real file. Negative control: reintroducing the four names turns the new check red and it names all four. There is also an in-file control that runs the same comparator over a fixed catalog, so it keeps proving the comparator can return something on the day the real catalog is correct.

Finding 3: confirmed. Only COMPUTER_USE_SEMANTIC_ACTIONS was exported, so computerUseModelCallArgs was unreachable from @maka/runtime and the whole headline fix was dead code while the harmful widening was the only part that shipped. The five missing symbols are exported now, and the projection is wired into projectPiToolArgs in pi-agent-backend.ts, which writes the persisted tool_call message and the tool_start event. Negative control: reverting that one line turns the pi-agent-backend projection test red with the approval dialect back in the diff.

Finding 4: confirmed and dropped rather than wired. ComputerUseSettings appears in none of AppSettings, UpdateAppSettingsInput, the defaults, the merge or the normalize pass, unlike every peer settings module, and select-backend.ts assembles the CU tools with no enable check anywhere. A type that says enabled: false while the shipped app always has it on is worse than no type. Wiring a real switch needs a UI and a migration and does not belong under a types commit.

Finding 5: confirmed, and it is exactly as described. text is six arguments under one name — the key for press_key, key and hold_key, the element action name for secondary_action, a screen substring for select_text, typed content for type. MODEL_CALL_PLAIN_VALUES is now a map from action to the argument names that are plain for that action. An action the tool does not accept has no entry, so it falls through to shapes rather than to whichever set was used last. Negative control: reverting to the name-keyed set turns two tests red, showing press_key coming back as text: .

Finding 6, partially rejected with evidence. dispatch_refused is gone. It is not a declaration — COMPUTER_USE_ERROR_CODES is a runtime value feeding isComputerUseErrorCode, which decides at cua-driver-result.ts:88 whether a raw string from the driver process is trusted or replaced with capture_failed. Widening that with no producer is a live change. The other five named items are different in kind. messageIsAppTextFree, truncated, actions, subrole and placeholder are optional fields on TypeScript interfaces with no runtime effect, and they are not distinguishable from about ten other unproduced declarations in the same diff that the review accepted — focused, appAlias, obscuringRects, menu, query, CuLaunchedApp, scroll_element, window_action, launchApp. Dropping the named five and keeping those would be arbitrary; dropping all of them empties the branch of its purpose. Declaring the shape an executor returns is what this branch is for, so they stay, and the absent-means-withheld polarity on messageIsAppTextFree is kept as suggested.

Also rebased onto current main, which the branch was one commit behind — the missing commit was #1870, the parity test finding 2 turns out to depend on.

Test delta, measured against a baseline taken on clean origin/main on the same machine. This machine's Node has no node:sqlite, so @maka/runtime carries 64 pre-existing failing test names there. After the change: 2722 tests, zero new failures and zero fixed against that set. @maka/core goes 703/703 to 710/710, the seven new ones being the model-call projection tests. biome check clean on the six touched files, check-console passes.

[hqhq1025]

Second-round review addressed. Two findings fixed, one dropped after checking, one scope decision.

Coordinates are back. The doc said typed text, written values and coordinates are screen-derived and stay out, and that is false for the third one: a coordinate is the model's own output, four digits it chose and sent. Reduced to <point>, a model that clicked [412, 88] and missed could not tell whether it had already tried that point, which is the repeated-call shape this projection exists to make visible. coordinate, start_coordinate and region now come back whole when they are integers and still degrade to a shape when they are not, so a malformed argument does not become a leak channel.

The out-of-enum action is reported as sent. On the AI SDK path the question is moot — a schema-rejected call never produces a tool-call part, so settleToolCall is never reached and no tool_start is emitted. But this projection's only consumer is the Pi backend, where tool_start arrives as a transport frame that Maka does not validate, so the case is live there. It is also wrong in principle: this record is the model's own arguments, and the action is one of them. Collapsing an unrecognised name is computerUseApprovalSummary's job, where knownAction decides what a person is asked to allow; a test now pins that the two functions disagree on purpose. The action is bounded and redacted like every other model-supplied string.

The declared-and-unconsumed set is dropped. launchApp, CuLaunchedApp, truncated, actions, subrole, placeholder, focused, menu, query, appAlias, obscuringRects, targetWindowId, targetStacking, messageIsAppTextFree, and the scroll_element and window_action members of CuSemanticAction — zero producers and zero consumers, confirmed by grep across packages and apps. The reason is the parity guard's own header: window_action sat in the strict union and not on the wire, was unreachable from the day it shipped, and nothing failed, because a declaration with no producer has nothing to check it. This branch was putting window_action back into that state with scroll_element beside it. computer-use-types.ts is now byte-identical to main; the additions come with the executor that produces them, where a guard can assert they arrive. The PR body has been rewritten so it no longer claims them.

What is left is what has a consumer: COMPUTER_USE_SEMANTIC_ACTIONS with the two-way parity check, and computerUseModelCallArgs wired into the Pi backend.

Negative controls, run rather than asserted. Reverting the geometry branch turned the coordinate tests red on coordinate: '<point>' against [412, 88]; restoring the APPROVAL_ACTIONS gate on action turned the third red on unknown against element_sequence, and the Pi backend's own projection test with it. Both back to green after restoring.

One thing I did not change, because it is outside this branch: tool-runtime.ts:776 still writes computerUseApprovalSummary(permissionArgs) into both the tool_start event and the persisted tool_call message on the AI SDK path. That is the same defect this PR fixes, on the main backend rather than the Pi one. It needs its own change, since the same value also feeds describeToolIntent, the durable args hash and the approval record.

Test delta against a clean rebuild of main on this machine: none in packages/core or the Computer Use tests. The rest of the run is shell, filesystem and host-process timing under load 40 on this box; each one passes when its file is run alone.

[hqhq1025]

Blocking finding addressed: the fix is moved to the path the shipping app runs.

It was wired into PiAgentBackend, which the desktop app never instantiates.
boot.ts registers only ai-sdk and fake; the pi backend is reachable only from
harbor-cell.ts behind MAKA_PI_*, driving an external CLI, and it does not
construct a ToolRuntime at all. tool-runtime.ts had a zero-byte diff, so on the
shipping path nothing changed. Measured on the real ToolRuntime, a model that
sent action press_key with app, window_id 41, observation_id obs-7, element_id
e12 and text cmd+s read back action, approvalClass, rememberForTurnAllowed,
app, windowId 41, observationId — a key the tool rejects, two fields it never
sent, no element, and a press_key with no key. That is now the one line the PR
changes in production.

The new assertion is on the tool_start event, which is what model-history.ts
replays, rather than on the projection function. Reverted to
computerUseApprovalSummary and rebuilt, it fails with exactly the diff above;
restored, it passes. A test calling computerUseModelCallArgs directly stays
green either way, which is how this survived being fixed once already.

On the coupling with #1888 and the privacy boundary, since the description
asked that it not be resolved silently.

computer-use-privacy-boundary.test.ts is not new to #1888; it has asserted this
line since #1581, and #1888 added an elementId case to it. Both PRs are
therefore changing the same invariant, and this one changes it in place rather
than around it, so what crosses is visible in the diff and is spelled out in
the file, the commit message and the PR body.

Two things now cross. element_id, which is an index the model chose into an
observation it had already read, admitted only when it is a stable identifier
so an accessibility label arriving under that key is dropped — this is exactly
what #1888 wanted and it is subsumed here, in the tool's own casing.
coordinate, start_coordinate and region, which are geometry the model wrote
into the call itself, integers only so a mistyped value still degrades to a
shape.

The argument for carrying coordinates is that they are the model's own output,
already present in the assistant turn that produced them, and that withholding
them leaves a model that clicked a point and missed unable to see that it had
already tried that point. The argument against, that for set_value and type
these are what the user was having typed on their behalf, does not apply to
coordinates: it applies to text and value, and those still do not cross. They
keep their key and lose their value to , because the key has to stay or
the model reads its own history as a call it never made. text for press_key,
key, hold_key and secondary_action is a name from a closed set the executor
publishes, so it is carried; that is one argument name meaning six things, and
only two of the six come from outside the model.

element_identity is added to the host-only set. The Computer Use tool's own
permissionArgs resolves the model's element_id against the live observation and
attaches its identity, and permissionArgs is what this projection now runs on,
so without that the model would read back a key it cannot send whose value came
off the accessibility tree.

For #1888 specifically: when the two are merged, computer-action-label.ts
should read window_id and element_id rather than windowId and elementId, since
the persisted args are now in the tool's dialect. Nothing on main reads the
persisted Computer Use args in the approval-summary dialect — the permission
prompt reads permissionArgs and the approval scope key is computed from the raw
call — so that renderer is the only reader affected.

Non-blocking finding: the title and body are rewritten. 0fcfb46 removed the
capability declarations, so the branch no longer does what it was named for;
what remains is the model-facing projection and the action-list parity guard,
and the description now says so and says what was dropped and why.

Rebased onto current main, cleanly. @maka/core and @maka/runtime suites pass,
npx biome check is clean on the touched files, and node scripts/check-console.mjs
passes.

[hqhq1025]

The record a model reads back of its own Computer Use call was the host's
approval projection, not the call. model-history.ts replays
event.content.args, and those args came from computerUseApprovalSummary,
which exists to decide and display a permission: it renames window_id to
windowId, adds approvalClass and rememberForTurnAllowed, and drops every
argument it does not need.

Measured on the real ToolRuntime, a model that sent

{"action":"press_key","app":"TextEdit","window_id":41,
"observation_id":"obs-7","element_id":"e12","text":"cmd+s"}

read back

{"action":"press_key","approvalClass":"keyboard_mutation",
"rememberForTurnAllowed":true,"app":"TextEdit","windowId":41,
"observationId":"obs-7"}

— a key the tool rejects, two fields it never sent, no element, and a
press_key with no key. A model imitates the shape it is shown, so it went on
calling it that way; a real desktop run failed six of eleven calls on shapes
copied from its own history.

This adds computerUseModelCallArgs: the same privacy rule, in the names the
tool accepts, and wires it at tool-runtime.ts, which is the line every
shipping backend goes through. The permission prompt still reads
permissionArgs and the approval scope key is still computed from the raw
call, so only what is written down changes.

What now crosses the privacy boundary

computer-use-privacy-boundary.test.ts asserted this line before this PR, and
it is updated in place rather than around, so the change is visible in the
diff. Two things cross that did not:

• element_id — an index the model chose into an observation it had already
  read (e12). Admitted only when it is a stable identifier, so an
  accessibility label arriving under that key is dropped rather than persisted.
  Without it, ten element actions in a turn are indistinguishable.
• coordinate, start_coordinate, region — geometry the model wrote into
  the call itself. Integers only, so a mistyped value still degrades to a
  shape. A coordinate is not read off the screen; withholding it leaves a model
  that clicked a point and missed unable to see that it had already tried that
  point.

What still does not cross: the value of text for type and select_text,
the value of set_value, and every other argument whose value is screen
content or something a person asked to have typed. Those keep their key and
lose their value to <text> — the key has to stay, or the model reads its own
history as a call it never made. text for press_key, key, hold_key and
secondary_action is a name from a closed set the executor publishes, so it is
carried: one argument name meaning six things, and only two of the six come
from outside the model.

element_identity joins approvalClass and rememberForTurnAllowed as
host-only. The Computer Use tool's own permissionArgs resolves the model's
element_id against the live observation and attaches it, and permissionArgs
is what this projection runs on.

Also here

COMPUTER_USE_SEMANTIC_ACTIONS replaces a hand-written action list that had
already drifted: window_action was added to the strict union and not to the
list, so every window move, resize and minimise would have summarised as
unknown — in the approval a person reads, and in the record the model reads
back. computer-use-schema-parity.test.ts now compares the two in both
directions.

Relationship to #1888

#1888 reached the same conclusion from the renderer's side and carried
elementId in the approval summary so its labels could tell two element rows
apart. That intent is subsumed here: element_id is carried, in the tool's own
casing. When the two are merged, #1888's computer-action-label.ts should read
window_id and element_id rather than windowId and elementId, and the
elementId case it added to computer-use-privacy-boundary.test.ts is covered
by the projection assertion in this branch.

Not here any more

The executor capability declarations this PR was originally titled for were
removed in 0fcfb46: nothing produced them, so they were a type surface with
no writer. The title and this description are rewritten to match what the
branch actually does.

Verification

The new assertion is on the tool_start event, not on the projection function.
Reverted to computerUseApprovalSummary at tool-runtime.ts and rebuilt, it
fails with exactly the diff quoted above; restored, it passes. A test that
calls computerUseModelCallArgs directly stays green either way, which is how
this survived being fixed once already in PiAgentBackend — a backend the
desktop app never instantiates.

@maka/core and @maka/runtime suites pass; npx biome check clean on the
touched files; node scripts/check-console.mjs passes. Rebased onto current
main, cleanly.

[hqhq1025]

Pushed fixes for all six findings. The claim in the PR body that nothing behaves differently was wrong, and finding 1 was the reason.

Finding 1, resolution: I scoped the constant to what main's schema accepts rather than stacking the PR on the executor branch. Verified first — main's wire enum at computer-use-tools.ts is list_apps, observe, click_element, set_value, select_text, secondary_action, press_key plus CU_ACTION_TYPES, and none of launch_app, scroll_element, element_sequence or window_action is in it. The four names went into APPROVAL_ACTIONS through COMPUTER_USE_SEMANTIC_ACTIONS, so computerUseApprovalSummary flipped knownAction to true for calls the SDK rejects before the tool runs, and rememberForTurnAllowed could evaluate true for the two that also joined SEMANTIC_ACTIONS. I chose scoping over stacking for two reasons. The constant's stated purpose is to be held against the tool schema, so declaring names the schema does not have is the same drift it exists to prevent, only in the direction nothing was checking. And stacking would make the PR unmergeable until the executor lands, which delays the parts that are correct today. The executor's vocabulary belongs on the branch that also ships the executor.

Finding 2: the promised file did not exist, but a guard did — computer-use-schema-parity.test.ts, added in #1870 after this branch was cut. It only walks from the schemas to the catalog, which catches a missing name and not an extra one, so the widening in finding 1 would have passed it. I added the reverse comparison to that file rather than creating the second one the comment named, and corrected the comment to point at the real file. Negative control: reintroducing the four names turns the new check red and it names all four. There is also an in-file control that runs the same comparator over a fixed catalog, so it keeps proving the comparator can return something on the day the real catalog is correct.

Finding 3: confirmed. Only COMPUTER_USE_SEMANTIC_ACTIONS was exported, so computerUseModelCallArgs was unreachable from @maka/runtime and the whole headline fix was dead code while the harmful widening was the only part that shipped. The five missing symbols are exported now, and the projection is wired into projectPiToolArgs in pi-agent-backend.ts, which writes the persisted tool_call message and the tool_start event. Negative control: reverting that one line turns the pi-agent-backend projection test red with the approval dialect back in the diff.

Finding 4: confirmed and dropped rather than wired. ComputerUseSettings appears in none of AppSettings, UpdateAppSettingsInput, the defaults, the merge or the normalize pass, unlike every peer settings module, and select-backend.ts assembles the CU tools with no enable check anywhere. A type that says enabled: false while the shipped app always has it on is worse than no type. Wiring a real switch needs a UI and a migration and does not belong under a types commit.

Finding 5: confirmed, and it is exactly as described. text is six arguments under one name — the key for press_key, key and hold_key, the element action name for secondary_action, a screen substring for select_text, typed content for type. MODEL_CALL_PLAIN_VALUES is now a map from action to the argument names that are plain for that action. An action the tool does not accept has no entry, so it falls through to shapes rather than to whichever set was used last. Negative control: reverting to the name-keyed set turns two tests red, showing press_key coming back as text: .

Finding 6, partially rejected with evidence. dispatch_refused is gone. It is not a declaration — COMPUTER_USE_ERROR_CODES is a runtime value feeding isComputerUseErrorCode, which decides at cua-driver-result.ts:88 whether a raw string from the driver process is trusted or replaced with capture_failed. Widening that with no producer is a live change. The other five named items are different in kind. messageIsAppTextFree, truncated, actions, subrole and placeholder are optional fields on TypeScript interfaces with no runtime effect, and they are not distinguishable from about ten other unproduced declarations in the same diff that the review accepted — focused, appAlias, obscuringRects, menu, query, CuLaunchedApp, scroll_element, window_action, launchApp. Dropping the named five and keeping those would be arbitrary; dropping all of them empties the branch of its purpose. Declaring the shape an executor returns is what this branch is for, so they stay, and the absent-means-withheld polarity on messageIsAppTextFree is kept as suggested.

Also rebased onto current main, which the branch was one commit behind — the missing commit was #1870, the parity test finding 2 turns out to depend on.

Test delta, measured against a baseline taken on clean origin/main on the same machine. This machine's Node has no node:sqlite, so @maka/runtime carries 64 pre-existing failing test names there. After the change: 2722 tests, zero new failures and zero fixed against that set. @maka/core goes 703/703 to 710/710, the seven new ones being the model-call projection tests. biome check clean on the six touched files, check-console passes.

[hqhq1025]

Second-round review addressed. Two findings fixed, one dropped after checking, one scope decision.

Coordinates are back. The doc said typed text, written values and coordinates are screen-derived and stay out, and that is false for the third one: a coordinate is the model's own output, four digits it chose and sent. Reduced to <point>, a model that clicked [412, 88] and missed could not tell whether it had already tried that point, which is the repeated-call shape this projection exists to make visible. coordinate, start_coordinate and region now come back whole when they are integers and still degrade to a shape when they are not, so a malformed argument does not become a leak channel.

The out-of-enum action is reported as sent. On the AI SDK path the question is moot — a schema-rejected call never produces a tool-call part, so settleToolCall is never reached and no tool_start is emitted. But this projection's only consumer is the Pi backend, where tool_start arrives as a transport frame that Maka does not validate, so the case is live there. It is also wrong in principle: this record is the model's own arguments, and the action is one of them. Collapsing an unrecognised name is computerUseApprovalSummary's job, where knownAction decides what a person is asked to allow; a test now pins that the two functions disagree on purpose. The action is bounded and redacted like every other model-supplied string.

The declared-and-unconsumed set is dropped. launchApp, CuLaunchedApp, truncated, actions, subrole, placeholder, focused, menu, query, appAlias, obscuringRects, targetWindowId, targetStacking, messageIsAppTextFree, and the scroll_element and window_action members of CuSemanticAction — zero producers and zero consumers, confirmed by grep across packages and apps. The reason is the parity guard's own header: window_action sat in the strict union and not on the wire, was unreachable from the day it shipped, and nothing failed, because a declaration with no producer has nothing to check it. This branch was putting window_action back into that state with scroll_element beside it. computer-use-types.ts is now byte-identical to main; the additions come with the executor that produces them, where a guard can assert they arrive. The PR body has been rewritten so it no longer claims them.

What is left is what has a consumer: COMPUTER_USE_SEMANTIC_ACTIONS with the two-way parity check, and computerUseModelCallArgs wired into the Pi backend.

Negative controls, run rather than asserted. Reverting the geometry branch turned the coordinate tests red on coordinate: '<point>' against [412, 88]; restoring the APPROVAL_ACTIONS gate on action turned the third red on unknown against element_sequence, and the Pi backend's own projection test with it. Both back to green after restoring.

One thing I did not change, because it is outside this branch: tool-runtime.ts:776 still writes computerUseApprovalSummary(permissionArgs) into both the tool_start event and the persisted tool_call message on the AI SDK path. That is the same defect this PR fixes, on the main backend rather than the Pi one. It needs its own change, since the same value also feeds describeToolIntent, the durable args hash and the approval record.

Test delta against a clean rebuild of main on this machine: none in packages/core or the Computer Use tests. The rest of the run is shell, filesystem and host-process timing under load 40 on this box; each one passes when its file is run alone.

[hqhq1025]

Blocking finding addressed: the fix is moved to the path the shipping app runs.

It was wired into PiAgentBackend, which the desktop app never instantiates.
boot.ts registers only ai-sdk and fake; the pi backend is reachable only from
harbor-cell.ts behind MAKA_PI_*, driving an external CLI, and it does not
construct a ToolRuntime at all. tool-runtime.ts had a zero-byte diff, so on the
shipping path nothing changed. Measured on the real ToolRuntime, a model that
sent action press_key with app, window_id 41, observation_id obs-7, element_id
e12 and text cmd+s read back action, approvalClass, rememberForTurnAllowed,
app, windowId 41, observationId — a key the tool rejects, two fields it never
sent, no element, and a press_key with no key. That is now the one line the PR
changes in production.

The new assertion is on the tool_start event, which is what model-history.ts
replays, rather than on the projection function. Reverted to
computerUseApprovalSummary and rebuilt, it fails with exactly the diff above;
restored, it passes. A test calling computerUseModelCallArgs directly stays
green either way, which is how this survived being fixed once already.

On the coupling with #1888 and the privacy boundary, since the description
asked that it not be resolved silently.

computer-use-privacy-boundary.test.ts is not new to #1888; it has asserted this
line since #1581, and #1888 added an elementId case to it. Both PRs are
therefore changing the same invariant, and this one changes it in place rather
than around it, so what crosses is visible in the diff and is spelled out in
the file, the commit message and the PR body.

Two things now cross. element_id, which is an index the model chose into an
observation it had already read, admitted only when it is a stable identifier
so an accessibility label arriving under that key is dropped — this is exactly
what #1888 wanted and it is subsumed here, in the tool's own casing.
coordinate, start_coordinate and region, which are geometry the model wrote
into the call itself, integers only so a mistyped value still degrades to a
shape.

The argument for carrying coordinates is that they are the model's own output,
already present in the assistant turn that produced them, and that withholding
them leaves a model that clicked a point and missed unable to see that it had
already tried that point. The argument against, that for set_value and type
these are what the user was having typed on their behalf, does not apply to
coordinates: it applies to text and value, and those still do not cross. They
keep their key and lose their value to , because the key has to stay or
the model reads its own history as a call it never made. text for press_key,
key, hold_key and secondary_action is a name from a closed set the executor
publishes, so it is carried; that is one argument name meaning six things, and
only two of the six come from outside the model.

element_identity is added to the host-only set. The Computer Use tool's own
permissionArgs resolves the model's element_id against the live observation and
attaches its identity, and permissionArgs is what this projection now runs on,
so without that the model would read back a key it cannot send whose value came
off the accessibility tree.

For #1888 specifically: when the two are merged, computer-action-label.ts
should read window_id and element_id rather than windowId and elementId, since
the persisted args are now in the tool's dialect. Nothing on main reads the
persisted Computer Use args in the approval-summary dialect — the permission
prompt reads permissionArgs and the approval scope key is computed from the raw
call — so that renderer is the only reader affected.

Non-blocking finding: the title and body are rewritten. 0fcfb46 removed the
capability declarations, so the branch no longer does what it was named for;
what remains is the model-facing projection and the action-list parity guard,
and the description now says so and says what was dropped and why.

Rebased onto current main, cleanly. @maka/core and @maka/runtime suites pass,
npx biome check is clean on the touched files, and node scripts/check-console.mjs
passes.

[hqhq1025]

The record a model reads back of its own Computer Use call was the host's
approval projection, not the call. model-history.ts replays
event.content.args, and those args came from computerUseApprovalSummary,
which exists to decide and display a permission: it renames window_id to
windowId, adds approvalClass and rememberForTurnAllowed, and drops every
argument it does not need.

Measured on the real ToolRuntime, a model that sent

{"action":"press_key","app":"TextEdit","window_id":41,
"observation_id":"obs-7","element_id":"e12","text":"cmd+s"}

read back

{"action":"press_key","approvalClass":"keyboard_mutation",
"rememberForTurnAllowed":true,"app":"TextEdit","windowId":41,
"observationId":"obs-7"}

— a key the tool rejects, two fields it never sent, no element, and a
press_key with no key. A model imitates the shape it is shown, so it went on
calling it that way; a real desktop run failed six of eleven calls on shapes
copied from its own history.

This adds computerUseModelCallArgs: the same privacy rule, in the names the
tool accepts, and wires it at tool-runtime.ts, which is the line every
shipping backend goes through. The permission prompt still reads
permissionArgs and the approval scope key is still computed from the raw
call, so only what is written down changes.

What now crosses the privacy boundary

computer-use-privacy-boundary.test.ts asserted this line before this PR, and
it is updated in place rather than around, so the change is visible in the
diff. Two things cross that did not:

• element_id — an index the model chose into an observation it had already
  read (e12). Admitted only when it is a stable identifier, so an
  accessibility label arriving under that key is dropped rather than persisted.
  Without it, ten element actions in a turn are indistinguishable.
• coordinate, start_coordinate, region — geometry the model wrote into
  the call itself. Integers only, so a mistyped value still degrades to a
  shape. A coordinate is not read off the screen; withholding it leaves a model
  that clicked a point and missed unable to see that it had already tried that
  point.

What still does not cross: the value of text for type and select_text,
the value of set_value, and every other argument whose value is screen
content or something a person asked to have typed. Those keep their key and
lose their value to <text> — the key has to stay, or the model reads its own
history as a call it never made. text for press_key, key, hold_key and
secondary_action is a name from a closed set the executor publishes, so it is
carried: one argument name meaning six things, and only two of the six come
from outside the model.

element_identity joins approvalClass and rememberForTurnAllowed as
host-only. The Computer Use tool's own permissionArgs resolves the model's
element_id against the live observation and attaches it, and permissionArgs
is what this projection runs on.

Also here

COMPUTER_USE_SEMANTIC_ACTIONS replaces a hand-written action list that had
already drifted: window_action was added to the strict union and not to the
list, so every window move, resize and minimise would have summarised as
unknown — in the approval a person reads, and in the record the model reads
back. computer-use-schema-parity.test.ts now compares the two in both
directions.

Relationship to #1888

#1888 reached the same conclusion from the renderer's side and carried
elementId in the approval summary so its labels could tell two element rows
apart. That intent is subsumed here: element_id is carried, in the tool's own
casing. When the two are merged, #1888's computer-action-label.ts should read
window_id and element_id rather than windowId and elementId, and the
elementId case it added to computer-use-privacy-boundary.test.ts is covered
by the projection assertion in this branch.

Not here any more

The executor capability declarations this PR was originally titled for were
removed in 0fcfb46: nothing produced them, so they were a type surface with
no writer. The title and this description are rewritten to match what the
branch actually does.

Verification

The new assertion is on the tool_start event, not on the projection function.
Reverted to computerUseApprovalSummary at tool-runtime.ts and rebuilt, it
fails with exactly the diff quoted above; restored, it passes. A test that
calls computerUseModelCallArgs directly stays green either way, which is how
this survived being fixed once already in PiAgentBackend — a backend the
desktop app never instantiates.

@maka/core and @maka/runtime suites pass; npx biome check clean on the
touched files; node scripts/check-console.mjs passes. Rebased onto current
main, cleanly.

[hqhq1025]

Pushed fixes for all six findings. The claim in the PR body that nothing behaves differently was wrong, and finding 1 was the reason.

Finding 1, resolution: I scoped the constant to what main's schema accepts rather than stacking the PR on the executor branch. Verified first — main's wire enum at computer-use-tools.ts is list_apps, observe, click_element, set_value, select_text, secondary_action, press_key plus CU_ACTION_TYPES, and none of launch_app, scroll_element, element_sequence or window_action is in it. The four names went into APPROVAL_ACTIONS through COMPUTER_USE_SEMANTIC_ACTIONS, so computerUseApprovalSummary flipped knownAction to true for calls the SDK rejects before the tool runs, and rememberForTurnAllowed could evaluate true for the two that also joined SEMANTIC_ACTIONS. I chose scoping over stacking for two reasons. The constant's stated purpose is to be held against the tool schema, so declaring names the schema does not have is the same drift it exists to prevent, only in the direction nothing was checking. And stacking would make the PR unmergeable until the executor lands, which delays the parts that are correct today. The executor's vocabulary belongs on the branch that also ships the executor.

Finding 2: the promised file did not exist, but a guard did — computer-use-schema-parity.test.ts, added in #1870 after this branch was cut. It only walks from the schemas to the catalog, which catches a missing name and not an extra one, so the widening in finding 1 would have passed it. I added the reverse comparison to that file rather than creating the second one the comment named, and corrected the comment to point at the real file. Negative control: reintroducing the four names turns the new check red and it names all four. There is also an in-file control that runs the same comparator over a fixed catalog, so it keeps proving the comparator can return something on the day the real catalog is correct.

Finding 3: confirmed. Only COMPUTER_USE_SEMANTIC_ACTIONS was exported, so computerUseModelCallArgs was unreachable from @maka/runtime and the whole headline fix was dead code while the harmful widening was the only part that shipped. The five missing symbols are exported now, and the projection is wired into projectPiToolArgs in pi-agent-backend.ts, which writes the persisted tool_call message and the tool_start event. Negative control: reverting that one line turns the pi-agent-backend projection test red with the approval dialect back in the diff.

Finding 4: confirmed and dropped rather than wired. ComputerUseSettings appears in none of AppSettings, UpdateAppSettingsInput, the defaults, the merge or the normalize pass, unlike every peer settings module, and select-backend.ts assembles the CU tools with no enable check anywhere. A type that says enabled: false while the shipped app always has it on is worse than no type. Wiring a real switch needs a UI and a migration and does not belong under a types commit.

Finding 5: confirmed, and it is exactly as described. text is six arguments under one name — the key for press_key, key and hold_key, the element action name for secondary_action, a screen substring for select_text, typed content for type. MODEL_CALL_PLAIN_VALUES is now a map from action to the argument names that are plain for that action. An action the tool does not accept has no entry, so it falls through to shapes rather than to whichever set was used last. Negative control: reverting to the name-keyed set turns two tests red, showing press_key coming back as text: .

Finding 6, partially rejected with evidence. dispatch_refused is gone. It is not a declaration — COMPUTER_USE_ERROR_CODES is a runtime value feeding isComputerUseErrorCode, which decides at cua-driver-result.ts:88 whether a raw string from the driver process is trusted or replaced with capture_failed. Widening that with no producer is a live change. The other five named items are different in kind. messageIsAppTextFree, truncated, actions, subrole and placeholder are optional fields on TypeScript interfaces with no runtime effect, and they are not distinguishable from about ten other unproduced declarations in the same diff that the review accepted — focused, appAlias, obscuringRects, menu, query, CuLaunchedApp, scroll_element, window_action, launchApp. Dropping the named five and keeping those would be arbitrary; dropping all of them empties the branch of its purpose. Declaring the shape an executor returns is what this branch is for, so they stay, and the absent-means-withheld polarity on messageIsAppTextFree is kept as suggested.

Also rebased onto current main, which the branch was one commit behind — the missing commit was #1870, the parity test finding 2 turns out to depend on.

Test delta, measured against a baseline taken on clean origin/main on the same machine. This machine's Node has no node:sqlite, so @maka/runtime carries 64 pre-existing failing test names there. After the change: 2722 tests, zero new failures and zero fixed against that set. @maka/core goes 703/703 to 710/710, the seven new ones being the model-call projection tests. biome check clean on the six touched files, check-console passes.

[hqhq1025]

Second-round review addressed. Two findings fixed, one dropped after checking, one scope decision.

Coordinates are back. The doc said typed text, written values and coordinates are screen-derived and stay out, and that is false for the third one: a coordinate is the model's own output, four digits it chose and sent. Reduced to <point>, a model that clicked [412, 88] and missed could not tell whether it had already tried that point, which is the repeated-call shape this projection exists to make visible. coordinate, start_coordinate and region now come back whole when they are integers and still degrade to a shape when they are not, so a malformed argument does not become a leak channel.

The out-of-enum action is reported as sent. On the AI SDK path the question is moot — a schema-rejected call never produces a tool-call part, so settleToolCall is never reached and no tool_start is emitted. But this projection's only consumer is the Pi backend, where tool_start arrives as a transport frame that Maka does not validate, so the case is live there. It is also wrong in principle: this record is the model's own arguments, and the action is one of them. Collapsing an unrecognised name is computerUseApprovalSummary's job, where knownAction decides what a person is asked to allow; a test now pins that the two functions disagree on purpose. The action is bounded and redacted like every other model-supplied string.

The declared-and-unconsumed set is dropped. launchApp, CuLaunchedApp, truncated, actions, subrole, placeholder, focused, menu, query, appAlias, obscuringRects, targetWindowId, targetStacking, messageIsAppTextFree, and the scroll_element and window_action members of CuSemanticAction — zero producers and zero consumers, confirmed by grep across packages and apps. The reason is the parity guard's own header: window_action sat in the strict union and not on the wire, was unreachable from the day it shipped, and nothing failed, because a declaration with no producer has nothing to check it. This branch was putting window_action back into that state with scroll_element beside it. computer-use-types.ts is now byte-identical to main; the additions come with the executor that produces them, where a guard can assert they arrive. The PR body has been rewritten so it no longer claims them.

What is left is what has a consumer: COMPUTER_USE_SEMANTIC_ACTIONS with the two-way parity check, and computerUseModelCallArgs wired into the Pi backend.

Negative controls, run rather than asserted. Reverting the geometry branch turned the coordinate tests red on coordinate: '<point>' against [412, 88]; restoring the APPROVAL_ACTIONS gate on action turned the third red on unknown against element_sequence, and the Pi backend's own projection test with it. Both back to green after restoring.

One thing I did not change, because it is outside this branch: tool-runtime.ts:776 still writes computerUseApprovalSummary(permissionArgs) into both the tool_start event and the persisted tool_call message on the AI SDK path. That is the same defect this PR fixes, on the main backend rather than the Pi one. It needs its own change, since the same value also feeds describeToolIntent, the durable args hash and the approval record.

Test delta against a clean rebuild of main on this machine: none in packages/core or the Computer Use tests. The rest of the run is shell, filesystem and host-process timing under load 40 on this box; each one passes when its file is run alone.

[hqhq1025]

Blocking finding addressed: the fix is moved to the path the shipping app runs.

It was wired into PiAgentBackend, which the desktop app never instantiates.
boot.ts registers only ai-sdk and fake; the pi backend is reachable only from
harbor-cell.ts behind MAKA_PI_*, driving an external CLI, and it does not
construct a ToolRuntime at all. tool-runtime.ts had a zero-byte diff, so on the
shipping path nothing changed. Measured on the real ToolRuntime, a model that
sent action press_key with app, window_id 41, observation_id obs-7, element_id
e12 and text cmd+s read back action, approvalClass, rememberForTurnAllowed,
app, windowId 41, observationId — a key the tool rejects, two fields it never
sent, no element, and a press_key with no key. That is now the one line the PR
changes in production.

The new assertion is on the tool_start event, which is what model-history.ts
replays, rather than on the projection function. Reverted to
computerUseApprovalSummary and rebuilt, it fails with exactly the diff above;
restored, it passes. A test calling computerUseModelCallArgs directly stays
green either way, which is how this survived being fixed once already.

On the coupling with #1888 and the privacy boundary, since the description
asked that it not be resolved silently.

computer-use-privacy-boundary.test.ts is not new to #1888; it has asserted this
line since #1581, and #1888 added an elementId case to it. Both PRs are
therefore changing the same invariant, and this one changes it in place rather
than around it, so what crosses is visible in the diff and is spelled out in
the file, the commit message and the PR body.

Two things now cross. element_id, which is an index the model chose into an
observation it had already read, admitted only when it is a stable identifier
so an accessibility label arriving under that key is dropped — this is exactly
what #1888 wanted and it is subsumed here, in the tool's own casing.
coordinate, start_coordinate and region, which are geometry the model wrote
into the call itself, integers only so a mistyped value still degrades to a
shape.

The argument for carrying coordinates is that they are the model's own output,
already present in the assistant turn that produced them, and that withholding
them leaves a model that clicked a point and missed unable to see that it had
already tried that point. The argument against, that for set_value and type
these are what the user was having typed on their behalf, does not apply to
coordinates: it applies to text and value, and those still do not cross. They
keep their key and lose their value to , because the key has to stay or
the model reads its own history as a call it never made. text for press_key,
key, hold_key and secondary_action is a name from a closed set the executor
publishes, so it is carried; that is one argument name meaning six things, and
only two of the six come from outside the model.

element_identity is added to the host-only set. The Computer Use tool's own
permissionArgs resolves the model's element_id against the live observation and
attaches its identity, and permissionArgs is what this projection now runs on,
so without that the model would read back a key it cannot send whose value came
off the accessibility tree.

For #1888 specifically: when the two are merged, computer-action-label.ts
should read window_id and element_id rather than windowId and elementId, since
the persisted args are now in the tool's dialect. Nothing on main reads the
persisted Computer Use args in the approval-summary dialect — the permission
prompt reads permissionArgs and the approval scope key is computed from the raw
call — so that renderer is the only reader affected.

Non-blocking finding: the title and body are rewritten. 0fcfb46 removed the
capability declarations, so the branch no longer does what it was named for;
what remains is the model-facing projection and the action-list parity guard,
and the description now says so and says what was dropped and why.

Rebased onto current main, cleanly. @maka/core and @maka/runtime suites pass,
npx biome check is clean on the touched files, and node scripts/check-console.mjs
passes.

[hqhq1025]

The record a model reads back of its own Computer Use call was the host's
approval projection, not the call. model-history.ts replays
event.content.args, and those args came from computerUseApprovalSummary,
which exists to decide and display a permission: it renames window_id to
windowId, adds approvalClass and rememberForTurnAllowed, and drops every
argument it does not need.

Measured on the real ToolRuntime, a model that sent

{"action":"press_key","app":"TextEdit","window_id":41,
"observation_id":"obs-7","element_id":"e12","text":"cmd+s"}

read back

{"action":"press_key","approvalClass":"keyboard_mutation",
"rememberForTurnAllowed":true,"app":"TextEdit","windowId":41,
"observationId":"obs-7"}

— a key the tool rejects, two fields it never sent, no element, and a
press_key with no key. A model imitates the shape it is shown, so it went on
calling it that way; a real desktop run failed six of eleven calls on shapes
copied from its own history.

This adds computerUseModelCallArgs: the same privacy rule, in the names the
tool accepts, and wires it at tool-runtime.ts, which is the line every
shipping backend goes through. The permission prompt still reads
permissionArgs and the approval scope key is still computed from the raw
call, so only what is written down changes.

What now crosses the privacy boundary

computer-use-privacy-boundary.test.ts asserted this line before this PR, and
it is updated in place rather than around, so the change is visible in the
diff. Two things cross that did not:

• element_id — an index the model chose into an observation it had already
  read (e12). Admitted only when it is a stable identifier, so an
  accessibility label arriving under that key is dropped rather than persisted.
  Without it, ten element actions in a turn are indistinguishable.
• coordinate, start_coordinate, region — geometry the model wrote into
  the call itself. Integers only, so a mistyped value still degrades to a
  shape. A coordinate is not read off the screen; withholding it leaves a model
  that clicked a point and missed unable to see that it had already tried that
  point.

What still does not cross: the value of text for type and select_text,
the value of set_value, and every other argument whose value is screen
content or something a person asked to have typed. Those keep their key and
lose their value to <text> — the key has to stay, or the model reads its own
history as a call it never made. text for press_key, key, hold_key and
secondary_action is a name from a closed set the executor publishes, so it is
carried: one argument name meaning six things, and only two of the six come
from outside the model.

element_identity joins approvalClass and rememberForTurnAllowed as
host-only. The Computer Use tool's own permissionArgs resolves the model's
element_id against the live observation and attaches it, and permissionArgs
is what this projection runs on.

Also here

COMPUTER_USE_SEMANTIC_ACTIONS replaces a hand-written action list that had
already drifted: window_action was added to the strict union and not to the
list, so every window move, resize and minimise would have summarised as
unknown — in the approval a person reads, and in the record the model reads
back. computer-use-schema-parity.test.ts now compares the two in both
directions.

Relationship to #1888

#1888 reached the same conclusion from the renderer's side and carried
elementId in the approval summary so its labels could tell two element rows
apart. That intent is subsumed here: element_id is carried, in the tool's own
casing. When the two are merged, #1888's computer-action-label.ts should read
window_id and element_id rather than windowId and elementId, and the
elementId case it added to computer-use-privacy-boundary.test.ts is covered
by the projection assertion in this branch.

Not here any more

The executor capability declarations this PR was originally titled for were
removed in 0fcfb46: nothing produced them, so they were a type surface with
no writer. The title and this description are rewritten to match what the
branch actually does.

Verification

The new assertion is on the tool_start event, not on the projection function.
Reverted to computerUseApprovalSummary at tool-runtime.ts and rebuilt, it
fails with exactly the diff quoted above; restored, it passes. A test that
calls computerUseModelCallArgs directly stays green either way, which is how
this survived being fixed once already in PiAgentBackend — a backend the
desktop app never instantiates.

@maka/core and @maka/runtime suites pass; npx biome check clean on the
touched files; node scripts/check-console.mjs passes. Rebased onto current
main, cleanly.

[hqhq1025]

Pushed fixes for all six findings. The claim in the PR body that nothing behaves differently was wrong, and finding 1 was the reason.

Finding 1, resolution: I scoped the constant to what main's schema accepts rather than stacking the PR on the executor branch. Verified first — main's wire enum at computer-use-tools.ts is list_apps, observe, click_element, set_value, select_text, secondary_action, press_key plus CU_ACTION_TYPES, and none of launch_app, scroll_element, element_sequence or window_action is in it. The four names went into APPROVAL_ACTIONS through COMPUTER_USE_SEMANTIC_ACTIONS, so computerUseApprovalSummary flipped knownAction to true for calls the SDK rejects before the tool runs, and rememberForTurnAllowed could evaluate true for the two that also joined SEMANTIC_ACTIONS. I chose scoping over stacking for two reasons. The constant's stated purpose is to be held against the tool schema, so declaring names the schema does not have is the same drift it exists to prevent, only in the direction nothing was checking. And stacking would make the PR unmergeable until the executor lands, which delays the parts that are correct today. The executor's vocabulary belongs on the branch that also ships the executor.

Finding 2: the promised file did not exist, but a guard did — computer-use-schema-parity.test.ts, added in #1870 after this branch was cut. It only walks from the schemas to the catalog, which catches a missing name and not an extra one, so the widening in finding 1 would have passed it. I added the reverse comparison to that file rather than creating the second one the comment named, and corrected the comment to point at the real file. Negative control: reintroducing the four names turns the new check red and it names all four. There is also an in-file control that runs the same comparator over a fixed catalog, so it keeps proving the comparator can return something on the day the real catalog is correct.

Finding 3: confirmed. Only COMPUTER_USE_SEMANTIC_ACTIONS was exported, so computerUseModelCallArgs was unreachable from @maka/runtime and the whole headline fix was dead code while the harmful widening was the only part that shipped. The five missing symbols are exported now, and the projection is wired into projectPiToolArgs in pi-agent-backend.ts, which writes the persisted tool_call message and the tool_start event. Negative control: reverting that one line turns the pi-agent-backend projection test red with the approval dialect back in the diff.

Finding 4: confirmed and dropped rather than wired. ComputerUseSettings appears in none of AppSettings, UpdateAppSettingsInput, the defaults, the merge or the normalize pass, unlike every peer settings module, and select-backend.ts assembles the CU tools with no enable check anywhere. A type that says enabled: false while the shipped app always has it on is worse than no type. Wiring a real switch needs a UI and a migration and does not belong under a types commit.

Finding 5: confirmed, and it is exactly as described. text is six arguments under one name — the key for press_key, key and hold_key, the element action name for secondary_action, a screen substring for select_text, typed content for type. MODEL_CALL_PLAIN_VALUES is now a map from action to the argument names that are plain for that action. An action the tool does not accept has no entry, so it falls through to shapes rather than to whichever set was used last. Negative control: reverting to the name-keyed set turns two tests red, showing press_key coming back as text: .

Finding 6, partially rejected with evidence. dispatch_refused is gone. It is not a declaration — COMPUTER_USE_ERROR_CODES is a runtime value feeding isComputerUseErrorCode, which decides at cua-driver-result.ts:88 whether a raw string from the driver process is trusted or replaced with capture_failed. Widening that with no producer is a live change. The other five named items are different in kind. messageIsAppTextFree, truncated, actions, subrole and placeholder are optional fields on TypeScript interfaces with no runtime effect, and they are not distinguishable from about ten other unproduced declarations in the same diff that the review accepted — focused, appAlias, obscuringRects, menu, query, CuLaunchedApp, scroll_element, window_action, launchApp. Dropping the named five and keeping those would be arbitrary; dropping all of them empties the branch of its purpose. Declaring the shape an executor returns is what this branch is for, so they stay, and the absent-means-withheld polarity on messageIsAppTextFree is kept as suggested.

Also rebased onto current main, which the branch was one commit behind — the missing commit was #1870, the parity test finding 2 turns out to depend on.

Test delta, measured against a baseline taken on clean origin/main on the same machine. This machine's Node has no node:sqlite, so @maka/runtime carries 64 pre-existing failing test names there. After the change: 2722 tests, zero new failures and zero fixed against that set. @maka/core goes 703/703 to 710/710, the seven new ones being the model-call projection tests. biome check clean on the six touched files, check-console passes.

[hqhq1025]

Second-round review addressed. Two findings fixed, one dropped after checking, one scope decision.

Coordinates are back. The doc said typed text, written values and coordinates are screen-derived and stay out, and that is false for the third one: a coordinate is the model's own output, four digits it chose and sent. Reduced to <point>, a model that clicked [412, 88] and missed could not tell whether it had already tried that point, which is the repeated-call shape this projection exists to make visible. coordinate, start_coordinate and region now come back whole when they are integers and still degrade to a shape when they are not, so a malformed argument does not become a leak channel.

The out-of-enum action is reported as sent. On the AI SDK path the question is moot — a schema-rejected call never produces a tool-call part, so settleToolCall is never reached and no tool_start is emitted. But this projection's only consumer is the Pi backend, where tool_start arrives as a transport frame that Maka does not validate, so the case is live there. It is also wrong in principle: this record is the model's own arguments, and the action is one of them. Collapsing an unrecognised name is computerUseApprovalSummary's job, where knownAction decides what a person is asked to allow; a test now pins that the two functions disagree on purpose. The action is bounded and redacted like every other model-supplied string.

The declared-and-unconsumed set is dropped. launchApp, CuLaunchedApp, truncated, actions, subrole, placeholder, focused, menu, query, appAlias, obscuringRects, targetWindowId, targetStacking, messageIsAppTextFree, and the scroll_element and window_action members of CuSemanticAction — zero producers and zero consumers, confirmed by grep across packages and apps. The reason is the parity guard's own header: window_action sat in the strict union and not on the wire, was unreachable from the day it shipped, and nothing failed, because a declaration with no producer has nothing to check it. This branch was putting window_action back into that state with scroll_element beside it. computer-use-types.ts is now byte-identical to main; the additions come with the executor that produces them, where a guard can assert they arrive. The PR body has been rewritten so it no longer claims them.

What is left is what has a consumer: COMPUTER_USE_SEMANTIC_ACTIONS with the two-way parity check, and computerUseModelCallArgs wired into the Pi backend.

Negative controls, run rather than asserted. Reverting the geometry branch turned the coordinate tests red on coordinate: '<point>' against [412, 88]; restoring the APPROVAL_ACTIONS gate on action turned the third red on unknown against element_sequence, and the Pi backend's own projection test with it. Both back to green after restoring.

One thing I did not change, because it is outside this branch: tool-runtime.ts:776 still writes computerUseApprovalSummary(permissionArgs) into both the tool_start event and the persisted tool_call message on the AI SDK path. That is the same defect this PR fixes, on the main backend rather than the Pi one. It needs its own change, since the same value also feeds describeToolIntent, the durable args hash and the approval record.

Test delta against a clean rebuild of main on this machine: none in packages/core or the Computer Use tests. The rest of the run is shell, filesystem and host-process timing under load 40 on this box; each one passes when its file is run alone.

[hqhq1025]

Blocking finding addressed: the fix is moved to the path the shipping app runs.

It was wired into PiAgentBackend, which the desktop app never instantiates.
boot.ts registers only ai-sdk and fake; the pi backend is reachable only from
harbor-cell.ts behind MAKA_PI_*, driving an external CLI, and it does not
construct a ToolRuntime at all. tool-runtime.ts had a zero-byte diff, so on the
shipping path nothing changed. Measured on the real ToolRuntime, a model that
sent action press_key with app, window_id 41, observation_id obs-7, element_id
e12 and text cmd+s read back action, approvalClass, rememberForTurnAllowed,
app, windowId 41, observationId — a key the tool rejects, two fields it never
sent, no element, and a press_key with no key. That is now the one line the PR
changes in production.

The new assertion is on the tool_start event, which is what model-history.ts
replays, rather than on the projection function. Reverted to
computerUseApprovalSummary and rebuilt, it fails with exactly the diff above;
restored, it passes. A test calling computerUseModelCallArgs directly stays
green either way, which is how this survived being fixed once already.

On the coupling with #1888 and the privacy boundary, since the description
asked that it not be resolved silently.

computer-use-privacy-boundary.test.ts is not new to #1888; it has asserted this
line since #1581, and #1888 added an elementId case to it. Both PRs are
therefore changing the same invariant, and this one changes it in place rather
than around it, so what crosses is visible in the diff and is spelled out in
the file, the commit message and the PR body.

Two things now cross. element_id, which is an index the model chose into an
observation it had already read, admitted only when it is a stable identifier
so an accessibility label arriving under that key is dropped — this is exactly
what #1888 wanted and it is subsumed here, in the tool's own casing.
coordinate, start_coordinate and region, which are geometry the model wrote
into the call itself, integers only so a mistyped value still degrades to a
shape.

The argument for carrying coordinates is that they are the model's own output,
already present in the assistant turn that produced them, and that withholding
them leaves a model that clicked a point and missed unable to see that it had
already tried that point. The argument against, that for set_value and type
these are what the user was having typed on their behalf, does not apply to
coordinates: it applies to text and value, and those still do not cross. They
keep their key and lose their value to , because the key has to stay or
the model reads its own history as a call it never made. text for press_key,
key, hold_key and secondary_action is a name from a closed set the executor
publishes, so it is carried; that is one argument name meaning six things, and
only two of the six come from outside the model.

element_identity is added to the host-only set. The Computer Use tool's own
permissionArgs resolves the model's element_id against the live observation and
attaches its identity, and permissionArgs is what this projection now runs on,
so without that the model would read back a key it cannot send whose value came
off the accessibility tree.

For #1888 specifically: when the two are merged, computer-action-label.ts
should read window_id and element_id rather than windowId and elementId, since
the persisted args are now in the tool's dialect. Nothing on main reads the
persisted Computer Use args in the approval-summary dialect — the permission
prompt reads permissionArgs and the approval scope key is computed from the raw
call — so that renderer is the only reader affected.

Non-blocking finding: the title and body are rewritten. 0fcfb46 removed the
capability declarations, so the branch no longer does what it was named for;
what remains is the model-facing projection and the action-list parity guard,
and the description now says so and says what was dropped and why.

Rebased onto current main, cleanly. @maka/core and @maka/runtime suites pass,
npx biome check is clean on the touched files, and node scripts/check-console.mjs
passes.