feat(computer-use): make maka-cu the executor that actually runs by hqhq1025 · Pull Request #1958 · apache/maka

hqhq1025 · 2026-08-03T07:23:33Z

This pull request is the second link in a three-part chain and its base is
pull request 1953, feat(computer-use): add maka-cu as a selectable executor
backend. The chain has to merge in order, because after the third link main
has no other executor.

What changes for a user

Computer Use now runs on maka-cu. Before this, maka-cu existed in the tree and
was reachable only by a caller that named it, and nothing named it, so
cua-driver was still the executor doing the work. This flips the default and
points the desktop host at it, which is the whole of the behaviour change.

Concretely: DEFAULT_CU_BACKEND_ID becomes maka-cu, and cua-driver is now
reached only by naming it, which its type makes mandatory. The selector's
branch is rewritten at the same time, because it tested deps.backendId ===
'maka-cu' rather than the resolved id: flipping the constant on its own would
have constructed a cua-driver backend and reported it as maka-cu, which is the
worst of both outcomes. The desktop host reads the makaCu entry of
bundled-tools.json, verifies resources/bin/maka-cu against the digest pinned
there, and deliberately asks for no backend id at all, so that "which executor
ships" stays one decision recorded in one place rather than a default and a
host that can quietly disagree about it. The host's health reporter collapses
from a pair of roles to a single state, because maka-cu supervises one child
rather than an action process and a capture process.

What is not changing yet

Synthetic keyboard and coordinate dispatch still fail closed.
allowCompatibilityInputDispatch stays off, so type, key, press_key and every
coordinate action are refused with the sentence that names the actions which do
work. Turning that on is a policy decision with its own argument to make and it
belongs in its own change.

maka-cu is still unsigned and still not distributed. Its distributionReady is
false and the DMG verifier still forbids its path in a packaged build, so a
packaged build continues to select no executor at all. This default takes
effect in a development build.

No tool schema changes. The model-facing surface, the observation format and
the approval classes are exactly what they were.

On the type widenings PR 1953 flagged

MakaCuObservation, MakaCuSemanticAction, MakaCuBackend and their neighbours stay
local to @maka/computer-use. This is not the change that should move them into
@maka/runtime. The reason those declarations are local is that
CuObservation and CuSemanticAction are the shared model-facing contract, and
widening them would add window_action, scroll_element and an element-targeted
press_key to a contract no tool schema can produce, plus observation fields no
tool renders. Moving the declarations up is only defensible together with the
tool layer that renders those fields and the wire schemas that produce those
actions. This change adds neither. It belongs in the change that makes the tool
surface read truncated, query, menu, obscuringRects and the per-element
subrole, placeholder and advertised actions, and that gives window_action and
scroll_element a wire schema. Until then, keeping them local costs nothing:
MakaCuObservation structurally is a CuObservation, so nothing downstream sees a
difference, and this package's own tests cover the extra branches.

Verification

npm --workspace @maka/computer-use run build and run test both pass.
npm run test:scripts, npm run format:check, npm run lint and
node scripts/check-console.mjs all pass. npm --workspace @maka/desktop run
build:main reports the same two pre-existing errors on this machine as it does
on the base branch, both from @maka/ui failing to build for an unrelated reason
here; the delta is zero and every main-process file in this change typechecks.
The desktop Computer Use host, tool-assembly and model-tools tests pass.
EOF

hqhq1025 · 2026-08-03T09:47:50Z

Rebased only, no content change on this branch. Its base #1953 was rebased onto current main so that the chain picks up computer-use-schema-parity — the old merge base was one commit before that test landed — and this branch was replayed onto the new #1953 head with no conflicts. #1959 was then replayed onto this one, also cleanly.

Nothing here was edited. Flagging it so the force-push is not read as a content change.

The previous change added maka-cu next to cua-driver and left it unreachable unless a caller named it. Nothing named it, so nothing ran it. This flips the default and points the desktop host at it, which is the whole of the behaviour change. DEFAULT_CU_BACKEND_ID becomes maka-cu, and the selector's branch is rewritten so the default is the thing that routes rather than only the thing that gets reported: it read deps.backendId === 'maka-cu', so flipping the constant alone would have labelled a cua-driver backend 'maka-cu'. cua-driver is now reached by naming it, and naming it is required by its type. The desktop host reads the makaCu entry of bundled-tools.json, verifies resources/bin/maka-cu against the digest pinned there, and asks for no backend id at all so that "which executor ships" stays one decision in one place. Its health reporter collapses from a pair of roles to one state, because maka-cu supervises one child. Not changing yet: synthetic keyboard and coordinate dispatch still fail closed, and maka-cu is still unsigned and still not distributed, so a packaged build continues to select no executor.

maka-cu is the executor that runs (apache#1953, apache#1958), so the third-party one it replaced has no caller left. This deletes the cua-driver backend, service, snapshot, page-target, result and release modules with their tests, the preparation and bundle-check scripts, its vendored notice, its manifest entry and its artifact-integrity document. Shared modules stay: stdio-json-rpc, frame-budget, display-snapshot and abortable-delay are used by maka-cu. Nothing is renamed — CuaSessionState, CuaFrameState and CuaBoundAction describe sessions and frames, not the executor. The selector, the capability card and the boot wiring collapse to one executor. The selector loses the union and its two overloads; the health function reads one snapshot instead of reconciling an action/capture role pair; boot reads executorState directly rather than falling back from a serviceState that no longer exists anywhere. Two fixes travel with it. The process-restart soak still called backend.serviceState(), which maka-cu does not expose, so it threw a TypeError on round 1 inside the try — after the real work had succeeded — and wrote up a passing real-machine run as a failure; it now reads executorState() and compares one generation. A new scripts/cu-process-restart-harness.test.mjs reads the harness's own source for the backend methods it calls and asks a real backend whether they exist, so the next such drift fails in CI rather than on a real machine. verify-macos-arm64-dmg keeps forbidding both cua-driver paths, and macos-arm64-release.test.mjs now asserts every unsigned helper is checked: apps/desktop/resources/bin is gitignored, so a binary prepared before this change is still in developers' trees and would otherwise be packaged unnoticed. The provenance record becomes a single-executor record, and its test asserts the manifest pins no executor the record does not account for.

maka-cu is the executor that runs (#1953, #1958), so the third-party one it replaced has no caller left. This deletes the cua-driver backend, service, snapshot, page-target, result and release modules with their tests, the preparation and bundle-check scripts, its vendored notice, its manifest entry and its artifact-integrity document. Shared modules stay: stdio-json-rpc, frame-budget, display-snapshot and abortable-delay are used by maka-cu. Nothing is renamed — CuaSessionState, CuaFrameState and CuaBoundAction describe sessions and frames, not the executor. The selector, the capability card and the boot wiring collapse to one executor. The selector loses the union and its two overloads; the health function reads one snapshot instead of reconciling an action/capture role pair; boot reads executorState directly rather than falling back from a serviceState that no longer exists anywhere. Two fixes travel with it. The process-restart soak still called backend.serviceState(), which maka-cu does not expose, so it threw a TypeError on round 1 inside the try — after the real work had succeeded — and wrote up a passing real-machine run as a failure; it now reads executorState() and compares one generation. A new scripts/cu-process-restart-harness.test.mjs reads the harness's own source for the backend methods it calls and asks a real backend whether they exist, so the next such drift fails in CI rather than on a real machine. verify-macos-arm64-dmg keeps forbidding both cua-driver paths, and macos-arm64-release.test.mjs now asserts every unsigned helper is checked: apps/desktop/resources/bin is gitignored, so a binary prepared before this change is still in developers' trees and would otherwise be packaged unnoticed. The provenance record becomes a single-executor record, and its test asserts the manifest pins no executor the record does not account for.

hqhq1025 · 2026-08-03T07:23:33Z

This pull request is the second link in a three-part chain and its base is
pull request 1953, feat(computer-use): add maka-cu as a selectable executor
backend. The chain has to merge in order, because after the third link main
has no other executor.

What changes for a user

Computer Use now runs on maka-cu. Before this, maka-cu existed in the tree and
was reachable only by a caller that named it, and nothing named it, so
cua-driver was still the executor doing the work. This flips the default and
points the desktop host at it, which is the whole of the behaviour change.

Concretely: DEFAULT_CU_BACKEND_ID becomes maka-cu, and cua-driver is now
reached only by naming it, which its type makes mandatory. The selector's
branch is rewritten at the same time, because it tested deps.backendId ===
'maka-cu' rather than the resolved id: flipping the constant on its own would
have constructed a cua-driver backend and reported it as maka-cu, which is the
worst of both outcomes. The desktop host reads the makaCu entry of
bundled-tools.json, verifies resources/bin/maka-cu against the digest pinned
there, and deliberately asks for no backend id at all, so that "which executor
ships" stays one decision recorded in one place rather than a default and a
host that can quietly disagree about it. The host's health reporter collapses
from a pair of roles to a single state, because maka-cu supervises one child
rather than an action process and a capture process.

What is not changing yet

Synthetic keyboard and coordinate dispatch still fail closed.
allowCompatibilityInputDispatch stays off, so type, key, press_key and every
coordinate action are refused with the sentence that names the actions which do
work. Turning that on is a policy decision with its own argument to make and it
belongs in its own change.

maka-cu is still unsigned and still not distributed. Its distributionReady is
false and the DMG verifier still forbids its path in a packaged build, so a
packaged build continues to select no executor at all. This default takes
effect in a development build.

No tool schema changes. The model-facing surface, the observation format and
the approval classes are exactly what they were.

On the type widenings PR 1953 flagged

MakaCuObservation, MakaCuSemanticAction, MakaCuBackend and their neighbours stay
local to @maka/computer-use. This is not the change that should move them into
@maka/runtime. The reason those declarations are local is that
CuObservation and CuSemanticAction are the shared model-facing contract, and
widening them would add window_action, scroll_element and an element-targeted
press_key to a contract no tool schema can produce, plus observation fields no
tool renders. Moving the declarations up is only defensible together with the
tool layer that renders those fields and the wire schemas that produce those
actions. This change adds neither. It belongs in the change that makes the tool
surface read truncated, query, menu, obscuringRects and the per-element
subrole, placeholder and advertised actions, and that gives window_action and
scroll_element a wire schema. Until then, keeping them local costs nothing:
MakaCuObservation structurally is a CuObservation, so nothing downstream sees a
difference, and this package's own tests cover the extra branches.

Verification

npm --workspace @maka/computer-use run build and run test both pass.
npm run test:scripts, npm run format:check, npm run lint and
node scripts/check-console.mjs all pass. npm --workspace @maka/desktop run
build:main reports the same two pre-existing errors on this machine as it does
on the base branch, both from @maka/ui failing to build for an unrelated reason
here; the delta is zero and every main-process file in this change typechecks.
The desktop Computer Use host, tool-assembly and model-tools tests pass.
EOF

hqhq1025 · 2026-08-03T09:47:50Z

Rebased only, no content change on this branch. Its base #1953 was rebased onto current main so that the chain picks up computer-use-schema-parity — the old merge base was one commit before that test landed — and this branch was replayed onto the new #1953 head with no conflicts. #1959 was then replayed onto this one, also cleanly.

Nothing here was edited. Flagging it so the force-push is not read as a content change.

The previous change added maka-cu next to cua-driver and left it unreachable unless a caller named it. Nothing named it, so nothing ran it. This flips the default and points the desktop host at it, which is the whole of the behaviour change. DEFAULT_CU_BACKEND_ID becomes maka-cu, and the selector's branch is rewritten so the default is the thing that routes rather than only the thing that gets reported: it read deps.backendId === 'maka-cu', so flipping the constant alone would have labelled a cua-driver backend 'maka-cu'. cua-driver is now reached by naming it, and naming it is required by its type. The desktop host reads the makaCu entry of bundled-tools.json, verifies resources/bin/maka-cu against the digest pinned there, and asks for no backend id at all so that "which executor ships" stays one decision in one place. Its health reporter collapses from a pair of roles to one state, because maka-cu supervises one child. Not changing yet: synthetic keyboard and coordinate dispatch still fail closed, and maka-cu is still unsigned and still not distributed, so a packaged build continues to select no executor.

maka-cu is the executor that runs (apache#1953, apache#1958), so the third-party one it replaced has no caller left. This deletes the cua-driver backend, service, snapshot, page-target, result and release modules with their tests, the preparation and bundle-check scripts, its vendored notice, its manifest entry and its artifact-integrity document. Shared modules stay: stdio-json-rpc, frame-budget, display-snapshot and abortable-delay are used by maka-cu. Nothing is renamed — CuaSessionState, CuaFrameState and CuaBoundAction describe sessions and frames, not the executor. The selector, the capability card and the boot wiring collapse to one executor. The selector loses the union and its two overloads; the health function reads one snapshot instead of reconciling an action/capture role pair; boot reads executorState directly rather than falling back from a serviceState that no longer exists anywhere. Two fixes travel with it. The process-restart soak still called backend.serviceState(), which maka-cu does not expose, so it threw a TypeError on round 1 inside the try — after the real work had succeeded — and wrote up a passing real-machine run as a failure; it now reads executorState() and compares one generation. A new scripts/cu-process-restart-harness.test.mjs reads the harness's own source for the backend methods it calls and asks a real backend whether they exist, so the next such drift fails in CI rather than on a real machine. verify-macos-arm64-dmg keeps forbidding both cua-driver paths, and macos-arm64-release.test.mjs now asserts every unsigned helper is checked: apps/desktop/resources/bin is gitignored, so a binary prepared before this change is still in developers' trees and would otherwise be packaged unnoticed. The provenance record becomes a single-executor record, and its test asserts the manifest pins no executor the record does not account for.

maka-cu is the executor that runs (#1953, #1958), so the third-party one it replaced has no caller left. This deletes the cua-driver backend, service, snapshot, page-target, result and release modules with their tests, the preparation and bundle-check scripts, its vendored notice, its manifest entry and its artifact-integrity document. Shared modules stay: stdio-json-rpc, frame-budget, display-snapshot and abortable-delay are used by maka-cu. Nothing is renamed — CuaSessionState, CuaFrameState and CuaBoundAction describe sessions and frames, not the executor. The selector, the capability card and the boot wiring collapse to one executor. The selector loses the union and its two overloads; the health function reads one snapshot instead of reconciling an action/capture role pair; boot reads executorState directly rather than falling back from a serviceState that no longer exists anywhere. Two fixes travel with it. The process-restart soak still called backend.serviceState(), which maka-cu does not expose, so it threw a TypeError on round 1 inside the try — after the real work had succeeded — and wrote up a passing real-machine run as a failure; it now reads executorState() and compares one generation. A new scripts/cu-process-restart-harness.test.mjs reads the harness's own source for the backend methods it calls and asks a real backend whether they exist, so the next such drift fails in CI rather than on a real machine. verify-macos-arm64-dmg keeps forbidding both cua-driver paths, and macos-arm64-release.test.mjs now asserts every unsigned helper is checked: apps/desktop/resources/bin is gitignored, so a binary prepared before this change is still in developers' trees and would otherwise be packaged unnoticed. The provenance record becomes a single-executor record, and its test asserts the manifest pins no executor the record does not account for.

hqhq1025 · 2026-08-03T07:23:33Z

This pull request is the second link in a three-part chain and its base is
pull request 1953, feat(computer-use): add maka-cu as a selectable executor
backend. The chain has to merge in order, because after the third link main
has no other executor.

What changes for a user

Computer Use now runs on maka-cu. Before this, maka-cu existed in the tree and
was reachable only by a caller that named it, and nothing named it, so
cua-driver was still the executor doing the work. This flips the default and
points the desktop host at it, which is the whole of the behaviour change.

Concretely: DEFAULT_CU_BACKEND_ID becomes maka-cu, and cua-driver is now
reached only by naming it, which its type makes mandatory. The selector's
branch is rewritten at the same time, because it tested deps.backendId ===
'maka-cu' rather than the resolved id: flipping the constant on its own would
have constructed a cua-driver backend and reported it as maka-cu, which is the
worst of both outcomes. The desktop host reads the makaCu entry of
bundled-tools.json, verifies resources/bin/maka-cu against the digest pinned
there, and deliberately asks for no backend id at all, so that "which executor
ships" stays one decision recorded in one place rather than a default and a
host that can quietly disagree about it. The host's health reporter collapses
from a pair of roles to a single state, because maka-cu supervises one child
rather than an action process and a capture process.

What is not changing yet

Synthetic keyboard and coordinate dispatch still fail closed.
allowCompatibilityInputDispatch stays off, so type, key, press_key and every
coordinate action are refused with the sentence that names the actions which do
work. Turning that on is a policy decision with its own argument to make and it
belongs in its own change.

maka-cu is still unsigned and still not distributed. Its distributionReady is
false and the DMG verifier still forbids its path in a packaged build, so a
packaged build continues to select no executor at all. This default takes
effect in a development build.

No tool schema changes. The model-facing surface, the observation format and
the approval classes are exactly what they were.

On the type widenings PR 1953 flagged

MakaCuObservation, MakaCuSemanticAction, MakaCuBackend and their neighbours stay
local to @maka/computer-use. This is not the change that should move them into
@maka/runtime. The reason those declarations are local is that
CuObservation and CuSemanticAction are the shared model-facing contract, and
widening them would add window_action, scroll_element and an element-targeted
press_key to a contract no tool schema can produce, plus observation fields no
tool renders. Moving the declarations up is only defensible together with the
tool layer that renders those fields and the wire schemas that produce those
actions. This change adds neither. It belongs in the change that makes the tool
surface read truncated, query, menu, obscuringRects and the per-element
subrole, placeholder and advertised actions, and that gives window_action and
scroll_element a wire schema. Until then, keeping them local costs nothing:
MakaCuObservation structurally is a CuObservation, so nothing downstream sees a
difference, and this package's own tests cover the extra branches.

Verification

npm --workspace @maka/computer-use run build and run test both pass.
npm run test:scripts, npm run format:check, npm run lint and
node scripts/check-console.mjs all pass. npm --workspace @maka/desktop run
build:main reports the same two pre-existing errors on this machine as it does
on the base branch, both from @maka/ui failing to build for an unrelated reason
here; the delta is zero and every main-process file in this change typechecks.
The desktop Computer Use host, tool-assembly and model-tools tests pass.
EOF

hqhq1025 · 2026-08-03T09:47:50Z

Rebased only, no content change on this branch. Its base #1953 was rebased onto current main so that the chain picks up computer-use-schema-parity — the old merge base was one commit before that test landed — and this branch was replayed onto the new #1953 head with no conflicts. #1959 was then replayed onto this one, also cleanly.

Nothing here was edited. Flagging it so the force-push is not read as a content change.

The previous change added maka-cu next to cua-driver and left it unreachable unless a caller named it. Nothing named it, so nothing ran it. This flips the default and points the desktop host at it, which is the whole of the behaviour change. DEFAULT_CU_BACKEND_ID becomes maka-cu, and the selector's branch is rewritten so the default is the thing that routes rather than only the thing that gets reported: it read deps.backendId === 'maka-cu', so flipping the constant alone would have labelled a cua-driver backend 'maka-cu'. cua-driver is now reached by naming it, and naming it is required by its type. The desktop host reads the makaCu entry of bundled-tools.json, verifies resources/bin/maka-cu against the digest pinned there, and asks for no backend id at all so that "which executor ships" stays one decision in one place. Its health reporter collapses from a pair of roles to one state, because maka-cu supervises one child. Not changing yet: synthetic keyboard and coordinate dispatch still fail closed, and maka-cu is still unsigned and still not distributed, so a packaged build continues to select no executor.

maka-cu is the executor that runs (apache#1953, apache#1958), so the third-party one it replaced has no caller left. This deletes the cua-driver backend, service, snapshot, page-target, result and release modules with their tests, the preparation and bundle-check scripts, its vendored notice, its manifest entry and its artifact-integrity document. Shared modules stay: stdio-json-rpc, frame-budget, display-snapshot and abortable-delay are used by maka-cu. Nothing is renamed — CuaSessionState, CuaFrameState and CuaBoundAction describe sessions and frames, not the executor. The selector, the capability card and the boot wiring collapse to one executor. The selector loses the union and its two overloads; the health function reads one snapshot instead of reconciling an action/capture role pair; boot reads executorState directly rather than falling back from a serviceState that no longer exists anywhere. Two fixes travel with it. The process-restart soak still called backend.serviceState(), which maka-cu does not expose, so it threw a TypeError on round 1 inside the try — after the real work had succeeded — and wrote up a passing real-machine run as a failure; it now reads executorState() and compares one generation. A new scripts/cu-process-restart-harness.test.mjs reads the harness's own source for the backend methods it calls and asks a real backend whether they exist, so the next such drift fails in CI rather than on a real machine. verify-macos-arm64-dmg keeps forbidding both cua-driver paths, and macos-arm64-release.test.mjs now asserts every unsigned helper is checked: apps/desktop/resources/bin is gitignored, so a binary prepared before this change is still in developers' trees and would otherwise be packaged unnoticed. The provenance record becomes a single-executor record, and its test asserts the manifest pins no executor the record does not account for.

maka-cu is the executor that runs (#1953, #1958), so the third-party one it replaced has no caller left. This deletes the cua-driver backend, service, snapshot, page-target, result and release modules with their tests, the preparation and bundle-check scripts, its vendored notice, its manifest entry and its artifact-integrity document. Shared modules stay: stdio-json-rpc, frame-budget, display-snapshot and abortable-delay are used by maka-cu. Nothing is renamed — CuaSessionState, CuaFrameState and CuaBoundAction describe sessions and frames, not the executor. The selector, the capability card and the boot wiring collapse to one executor. The selector loses the union and its two overloads; the health function reads one snapshot instead of reconciling an action/capture role pair; boot reads executorState directly rather than falling back from a serviceState that no longer exists anywhere. Two fixes travel with it. The process-restart soak still called backend.serviceState(), which maka-cu does not expose, so it threw a TypeError on round 1 inside the try — after the real work had succeeded — and wrote up a passing real-machine run as a failure; it now reads executorState() and compares one generation. A new scripts/cu-process-restart-harness.test.mjs reads the harness's own source for the backend methods it calls and asks a real backend whether they exist, so the next such drift fails in CI rather than on a real machine. verify-macos-arm64-dmg keeps forbidding both cua-driver paths, and macos-arm64-release.test.mjs now asserts every unsigned helper is checked: apps/desktop/resources/bin is gitignored, so a binary prepared before this change is still in developers' trees and would otherwise be packaged unnoticed. The provenance record becomes a single-executor record, and its test asserts the manifest pins no executor the record does not account for.

hqhq1025 · 2026-08-03T07:23:33Z

This pull request is the second link in a three-part chain and its base is
pull request 1953, feat(computer-use): add maka-cu as a selectable executor
backend. The chain has to merge in order, because after the third link main
has no other executor.

What changes for a user

Computer Use now runs on maka-cu. Before this, maka-cu existed in the tree and
was reachable only by a caller that named it, and nothing named it, so
cua-driver was still the executor doing the work. This flips the default and
points the desktop host at it, which is the whole of the behaviour change.

Concretely: DEFAULT_CU_BACKEND_ID becomes maka-cu, and cua-driver is now
reached only by naming it, which its type makes mandatory. The selector's
branch is rewritten at the same time, because it tested deps.backendId ===
'maka-cu' rather than the resolved id: flipping the constant on its own would
have constructed a cua-driver backend and reported it as maka-cu, which is the
worst of both outcomes. The desktop host reads the makaCu entry of
bundled-tools.json, verifies resources/bin/maka-cu against the digest pinned
there, and deliberately asks for no backend id at all, so that "which executor
ships" stays one decision recorded in one place rather than a default and a
host that can quietly disagree about it. The host's health reporter collapses
from a pair of roles to a single state, because maka-cu supervises one child
rather than an action process and a capture process.

What is not changing yet

Synthetic keyboard and coordinate dispatch still fail closed.
allowCompatibilityInputDispatch stays off, so type, key, press_key and every
coordinate action are refused with the sentence that names the actions which do
work. Turning that on is a policy decision with its own argument to make and it
belongs in its own change.

maka-cu is still unsigned and still not distributed. Its distributionReady is
false and the DMG verifier still forbids its path in a packaged build, so a
packaged build continues to select no executor at all. This default takes
effect in a development build.

No tool schema changes. The model-facing surface, the observation format and
the approval classes are exactly what they were.

On the type widenings PR 1953 flagged

MakaCuObservation, MakaCuSemanticAction, MakaCuBackend and their neighbours stay
local to @maka/computer-use. This is not the change that should move them into
@maka/runtime. The reason those declarations are local is that
CuObservation and CuSemanticAction are the shared model-facing contract, and
widening them would add window_action, scroll_element and an element-targeted
press_key to a contract no tool schema can produce, plus observation fields no
tool renders. Moving the declarations up is only defensible together with the
tool layer that renders those fields and the wire schemas that produce those
actions. This change adds neither. It belongs in the change that makes the tool
surface read truncated, query, menu, obscuringRects and the per-element
subrole, placeholder and advertised actions, and that gives window_action and
scroll_element a wire schema. Until then, keeping them local costs nothing:
MakaCuObservation structurally is a CuObservation, so nothing downstream sees a
difference, and this package's own tests cover the extra branches.

Verification

npm --workspace @maka/computer-use run build and run test both pass.
npm run test:scripts, npm run format:check, npm run lint and
node scripts/check-console.mjs all pass. npm --workspace @maka/desktop run
build:main reports the same two pre-existing errors on this machine as it does
on the base branch, both from @maka/ui failing to build for an unrelated reason
here; the delta is zero and every main-process file in this change typechecks.
The desktop Computer Use host, tool-assembly and model-tools tests pass.
EOF

hqhq1025 · 2026-08-03T09:47:50Z

Rebased only, no content change on this branch. Its base #1953 was rebased onto current main so that the chain picks up computer-use-schema-parity — the old merge base was one commit before that test landed — and this branch was replayed onto the new #1953 head with no conflicts. #1959 was then replayed onto this one, also cleanly.

Nothing here was edited. Flagging it so the force-push is not read as a content change.

The previous change added maka-cu next to cua-driver and left it unreachable unless a caller named it. Nothing named it, so nothing ran it. This flips the default and points the desktop host at it, which is the whole of the behaviour change. DEFAULT_CU_BACKEND_ID becomes maka-cu, and the selector's branch is rewritten so the default is the thing that routes rather than only the thing that gets reported: it read deps.backendId === 'maka-cu', so flipping the constant alone would have labelled a cua-driver backend 'maka-cu'. cua-driver is now reached by naming it, and naming it is required by its type. The desktop host reads the makaCu entry of bundled-tools.json, verifies resources/bin/maka-cu against the digest pinned there, and asks for no backend id at all so that "which executor ships" stays one decision in one place. Its health reporter collapses from a pair of roles to one state, because maka-cu supervises one child. Not changing yet: synthetic keyboard and coordinate dispatch still fail closed, and maka-cu is still unsigned and still not distributed, so a packaged build continues to select no executor.

maka-cu is the executor that runs (apache#1953, apache#1958), so the third-party one it replaced has no caller left. This deletes the cua-driver backend, service, snapshot, page-target, result and release modules with their tests, the preparation and bundle-check scripts, its vendored notice, its manifest entry and its artifact-integrity document. Shared modules stay: stdio-json-rpc, frame-budget, display-snapshot and abortable-delay are used by maka-cu. Nothing is renamed — CuaSessionState, CuaFrameState and CuaBoundAction describe sessions and frames, not the executor. The selector, the capability card and the boot wiring collapse to one executor. The selector loses the union and its two overloads; the health function reads one snapshot instead of reconciling an action/capture role pair; boot reads executorState directly rather than falling back from a serviceState that no longer exists anywhere. Two fixes travel with it. The process-restart soak still called backend.serviceState(), which maka-cu does not expose, so it threw a TypeError on round 1 inside the try — after the real work had succeeded — and wrote up a passing real-machine run as a failure; it now reads executorState() and compares one generation. A new scripts/cu-process-restart-harness.test.mjs reads the harness's own source for the backend methods it calls and asks a real backend whether they exist, so the next such drift fails in CI rather than on a real machine. verify-macos-arm64-dmg keeps forbidding both cua-driver paths, and macos-arm64-release.test.mjs now asserts every unsigned helper is checked: apps/desktop/resources/bin is gitignored, so a binary prepared before this change is still in developers' trees and would otherwise be packaged unnoticed. The provenance record becomes a single-executor record, and its test asserts the manifest pins no executor the record does not account for.

maka-cu is the executor that runs (#1953, #1958), so the third-party one it replaced has no caller left. This deletes the cua-driver backend, service, snapshot, page-target, result and release modules with their tests, the preparation and bundle-check scripts, its vendored notice, its manifest entry and its artifact-integrity document. Shared modules stay: stdio-json-rpc, frame-budget, display-snapshot and abortable-delay are used by maka-cu. Nothing is renamed — CuaSessionState, CuaFrameState and CuaBoundAction describe sessions and frames, not the executor. The selector, the capability card and the boot wiring collapse to one executor. The selector loses the union and its two overloads; the health function reads one snapshot instead of reconciling an action/capture role pair; boot reads executorState directly rather than falling back from a serviceState that no longer exists anywhere. Two fixes travel with it. The process-restart soak still called backend.serviceState(), which maka-cu does not expose, so it threw a TypeError on round 1 inside the try — after the real work had succeeded — and wrote up a passing real-machine run as a failure; it now reads executorState() and compares one generation. A new scripts/cu-process-restart-harness.test.mjs reads the harness's own source for the backend methods it calls and asks a real backend whether they exist, so the next such drift fails in CI rather than on a real machine. verify-macos-arm64-dmg keeps forbidding both cua-driver paths, and macos-arm64-release.test.mjs now asserts every unsigned helper is checked: apps/desktop/resources/bin is gitignored, so a binary prepared before this change is still in developers' trees and would otherwise be packaged unnoticed. The provenance record becomes a single-executor record, and its test asserts the manifest pins no executor the record does not account for.

hqhq1025 · 2026-08-03T07:23:33Z

This pull request is the second link in a three-part chain and its base is
pull request 1953, feat(computer-use): add maka-cu as a selectable executor
backend. The chain has to merge in order, because after the third link main
has no other executor.

What changes for a user

Computer Use now runs on maka-cu. Before this, maka-cu existed in the tree and
was reachable only by a caller that named it, and nothing named it, so
cua-driver was still the executor doing the work. This flips the default and
points the desktop host at it, which is the whole of the behaviour change.

Concretely: DEFAULT_CU_BACKEND_ID becomes maka-cu, and cua-driver is now
reached only by naming it, which its type makes mandatory. The selector's
branch is rewritten at the same time, because it tested deps.backendId ===
'maka-cu' rather than the resolved id: flipping the constant on its own would
have constructed a cua-driver backend and reported it as maka-cu, which is the
worst of both outcomes. The desktop host reads the makaCu entry of
bundled-tools.json, verifies resources/bin/maka-cu against the digest pinned
there, and deliberately asks for no backend id at all, so that "which executor
ships" stays one decision recorded in one place rather than a default and a
host that can quietly disagree about it. The host's health reporter collapses
from a pair of roles to a single state, because maka-cu supervises one child
rather than an action process and a capture process.

What is not changing yet

Synthetic keyboard and coordinate dispatch still fail closed.
allowCompatibilityInputDispatch stays off, so type, key, press_key and every
coordinate action are refused with the sentence that names the actions which do
work. Turning that on is a policy decision with its own argument to make and it
belongs in its own change.

maka-cu is still unsigned and still not distributed. Its distributionReady is
false and the DMG verifier still forbids its path in a packaged build, so a
packaged build continues to select no executor at all. This default takes
effect in a development build.

No tool schema changes. The model-facing surface, the observation format and
the approval classes are exactly what they were.

On the type widenings PR 1953 flagged

MakaCuObservation, MakaCuSemanticAction, MakaCuBackend and their neighbours stay
local to @maka/computer-use. This is not the change that should move them into
@maka/runtime. The reason those declarations are local is that
CuObservation and CuSemanticAction are the shared model-facing contract, and
widening them would add window_action, scroll_element and an element-targeted
press_key to a contract no tool schema can produce, plus observation fields no
tool renders. Moving the declarations up is only defensible together with the
tool layer that renders those fields and the wire schemas that produce those
actions. This change adds neither. It belongs in the change that makes the tool
surface read truncated, query, menu, obscuringRects and the per-element
subrole, placeholder and advertised actions, and that gives window_action and
scroll_element a wire schema. Until then, keeping them local costs nothing:
MakaCuObservation structurally is a CuObservation, so nothing downstream sees a
difference, and this package's own tests cover the extra branches.

Verification

npm --workspace @maka/computer-use run build and run test both pass.
npm run test:scripts, npm run format:check, npm run lint and
node scripts/check-console.mjs all pass. npm --workspace @maka/desktop run
build:main reports the same two pre-existing errors on this machine as it does
on the base branch, both from @maka/ui failing to build for an unrelated reason
here; the delta is zero and every main-process file in this change typechecks.
The desktop Computer Use host, tool-assembly and model-tools tests pass.
EOF

hqhq1025 · 2026-08-03T09:47:50Z

Rebased only, no content change on this branch. Its base #1953 was rebased onto current main so that the chain picks up computer-use-schema-parity — the old merge base was one commit before that test landed — and this branch was replayed onto the new #1953 head with no conflicts. #1959 was then replayed onto this one, also cleanly.

Nothing here was edited. Flagging it so the force-push is not read as a content change.

The previous change added maka-cu next to cua-driver and left it unreachable unless a caller named it. Nothing named it, so nothing ran it. This flips the default and points the desktop host at it, which is the whole of the behaviour change. DEFAULT_CU_BACKEND_ID becomes maka-cu, and the selector's branch is rewritten so the default is the thing that routes rather than only the thing that gets reported: it read deps.backendId === 'maka-cu', so flipping the constant alone would have labelled a cua-driver backend 'maka-cu'. cua-driver is now reached by naming it, and naming it is required by its type. The desktop host reads the makaCu entry of bundled-tools.json, verifies resources/bin/maka-cu against the digest pinned there, and asks for no backend id at all so that "which executor ships" stays one decision in one place. Its health reporter collapses from a pair of roles to one state, because maka-cu supervises one child. Not changing yet: synthetic keyboard and coordinate dispatch still fail closed, and maka-cu is still unsigned and still not distributed, so a packaged build continues to select no executor.

maka-cu is the executor that runs (apache#1953, apache#1958), so the third-party one it replaced has no caller left. This deletes the cua-driver backend, service, snapshot, page-target, result and release modules with their tests, the preparation and bundle-check scripts, its vendored notice, its manifest entry and its artifact-integrity document. Shared modules stay: stdio-json-rpc, frame-budget, display-snapshot and abortable-delay are used by maka-cu. Nothing is renamed — CuaSessionState, CuaFrameState and CuaBoundAction describe sessions and frames, not the executor. The selector, the capability card and the boot wiring collapse to one executor. The selector loses the union and its two overloads; the health function reads one snapshot instead of reconciling an action/capture role pair; boot reads executorState directly rather than falling back from a serviceState that no longer exists anywhere. Two fixes travel with it. The process-restart soak still called backend.serviceState(), which maka-cu does not expose, so it threw a TypeError on round 1 inside the try — after the real work had succeeded — and wrote up a passing real-machine run as a failure; it now reads executorState() and compares one generation. A new scripts/cu-process-restart-harness.test.mjs reads the harness's own source for the backend methods it calls and asks a real backend whether they exist, so the next such drift fails in CI rather than on a real machine. verify-macos-arm64-dmg keeps forbidding both cua-driver paths, and macos-arm64-release.test.mjs now asserts every unsigned helper is checked: apps/desktop/resources/bin is gitignored, so a binary prepared before this change is still in developers' trees and would otherwise be packaged unnoticed. The provenance record becomes a single-executor record, and its test asserts the manifest pins no executor the record does not account for.

maka-cu is the executor that runs (#1953, #1958), so the third-party one it replaced has no caller left. This deletes the cua-driver backend, service, snapshot, page-target, result and release modules with their tests, the preparation and bundle-check scripts, its vendored notice, its manifest entry and its artifact-integrity document. Shared modules stay: stdio-json-rpc, frame-budget, display-snapshot and abortable-delay are used by maka-cu. Nothing is renamed — CuaSessionState, CuaFrameState and CuaBoundAction describe sessions and frames, not the executor. The selector, the capability card and the boot wiring collapse to one executor. The selector loses the union and its two overloads; the health function reads one snapshot instead of reconciling an action/capture role pair; boot reads executorState directly rather than falling back from a serviceState that no longer exists anywhere. Two fixes travel with it. The process-restart soak still called backend.serviceState(), which maka-cu does not expose, so it threw a TypeError on round 1 inside the try — after the real work had succeeded — and wrote up a passing real-machine run as a failure; it now reads executorState() and compares one generation. A new scripts/cu-process-restart-harness.test.mjs reads the harness's own source for the backend methods it calls and asks a real backend whether they exist, so the next such drift fails in CI rather than on a real machine. verify-macos-arm64-dmg keeps forbidding both cua-driver paths, and macos-arm64-release.test.mjs now asserts every unsigned helper is checked: apps/desktop/resources/bin is gitignored, so a binary prepared before this change is still in developers' trees and would otherwise be packaged unnoticed. The provenance record becomes a single-executor record, and its test asserts the manifest pins no executor the record does not account for.

hqhq1025 · 2026-08-03T07:23:33Z

This pull request is the second link in a three-part chain and its base is
pull request 1953, feat(computer-use): add maka-cu as a selectable executor
backend. The chain has to merge in order, because after the third link main
has no other executor.

What changes for a user

Computer Use now runs on maka-cu. Before this, maka-cu existed in the tree and
was reachable only by a caller that named it, and nothing named it, so
cua-driver was still the executor doing the work. This flips the default and
points the desktop host at it, which is the whole of the behaviour change.

Concretely: DEFAULT_CU_BACKEND_ID becomes maka-cu, and cua-driver is now
reached only by naming it, which its type makes mandatory. The selector's
branch is rewritten at the same time, because it tested deps.backendId ===
'maka-cu' rather than the resolved id: flipping the constant on its own would
have constructed a cua-driver backend and reported it as maka-cu, which is the
worst of both outcomes. The desktop host reads the makaCu entry of
bundled-tools.json, verifies resources/bin/maka-cu against the digest pinned
there, and deliberately asks for no backend id at all, so that "which executor
ships" stays one decision recorded in one place rather than a default and a
host that can quietly disagree about it. The host's health reporter collapses
from a pair of roles to a single state, because maka-cu supervises one child
rather than an action process and a capture process.

What is not changing yet

Synthetic keyboard and coordinate dispatch still fail closed.
allowCompatibilityInputDispatch stays off, so type, key, press_key and every
coordinate action are refused with the sentence that names the actions which do
work. Turning that on is a policy decision with its own argument to make and it
belongs in its own change.

maka-cu is still unsigned and still not distributed. Its distributionReady is
false and the DMG verifier still forbids its path in a packaged build, so a
packaged build continues to select no executor at all. This default takes
effect in a development build.

No tool schema changes. The model-facing surface, the observation format and
the approval classes are exactly what they were.

On the type widenings PR 1953 flagged

MakaCuObservation, MakaCuSemanticAction, MakaCuBackend and their neighbours stay
local to @maka/computer-use. This is not the change that should move them into
@maka/runtime. The reason those declarations are local is that
CuObservation and CuSemanticAction are the shared model-facing contract, and
widening them would add window_action, scroll_element and an element-targeted
press_key to a contract no tool schema can produce, plus observation fields no
tool renders. Moving the declarations up is only defensible together with the
tool layer that renders those fields and the wire schemas that produce those
actions. This change adds neither. It belongs in the change that makes the tool
surface read truncated, query, menu, obscuringRects and the per-element
subrole, placeholder and advertised actions, and that gives window_action and
scroll_element a wire schema. Until then, keeping them local costs nothing:
MakaCuObservation structurally is a CuObservation, so nothing downstream sees a
difference, and this package's own tests cover the extra branches.

Verification

npm --workspace @maka/computer-use run build and run test both pass.
npm run test:scripts, npm run format:check, npm run lint and
node scripts/check-console.mjs all pass. npm --workspace @maka/desktop run
build:main reports the same two pre-existing errors on this machine as it does
on the base branch, both from @maka/ui failing to build for an unrelated reason
here; the delta is zero and every main-process file in this change typechecks.
The desktop Computer Use host, tool-assembly and model-tools tests pass.
EOF

hqhq1025 · 2026-08-03T09:47:50Z

Rebased only, no content change on this branch. Its base #1953 was rebased onto current main so that the chain picks up computer-use-schema-parity — the old merge base was one commit before that test landed — and this branch was replayed onto the new #1953 head with no conflicts. #1959 was then replayed onto this one, also cleanly.

Nothing here was edited. Flagging it so the force-push is not read as a content change.

The previous change added maka-cu next to cua-driver and left it unreachable unless a caller named it. Nothing named it, so nothing ran it. This flips the default and points the desktop host at it, which is the whole of the behaviour change. DEFAULT_CU_BACKEND_ID becomes maka-cu, and the selector's branch is rewritten so the default is the thing that routes rather than only the thing that gets reported: it read deps.backendId === 'maka-cu', so flipping the constant alone would have labelled a cua-driver backend 'maka-cu'. cua-driver is now reached by naming it, and naming it is required by its type. The desktop host reads the makaCu entry of bundled-tools.json, verifies resources/bin/maka-cu against the digest pinned there, and asks for no backend id at all so that "which executor ships" stays one decision in one place. Its health reporter collapses from a pair of roles to one state, because maka-cu supervises one child. Not changing yet: synthetic keyboard and coordinate dispatch still fail closed, and maka-cu is still unsigned and still not distributed, so a packaged build continues to select no executor.

maka-cu is the executor that runs (apache#1953, apache#1958), so the third-party one it replaced has no caller left. This deletes the cua-driver backend, service, snapshot, page-target, result and release modules with their tests, the preparation and bundle-check scripts, its vendored notice, its manifest entry and its artifact-integrity document. Shared modules stay: stdio-json-rpc, frame-budget, display-snapshot and abortable-delay are used by maka-cu. Nothing is renamed — CuaSessionState, CuaFrameState and CuaBoundAction describe sessions and frames, not the executor. The selector, the capability card and the boot wiring collapse to one executor. The selector loses the union and its two overloads; the health function reads one snapshot instead of reconciling an action/capture role pair; boot reads executorState directly rather than falling back from a serviceState that no longer exists anywhere. Two fixes travel with it. The process-restart soak still called backend.serviceState(), which maka-cu does not expose, so it threw a TypeError on round 1 inside the try — after the real work had succeeded — and wrote up a passing real-machine run as a failure; it now reads executorState() and compares one generation. A new scripts/cu-process-restart-harness.test.mjs reads the harness's own source for the backend methods it calls and asks a real backend whether they exist, so the next such drift fails in CI rather than on a real machine. verify-macos-arm64-dmg keeps forbidding both cua-driver paths, and macos-arm64-release.test.mjs now asserts every unsigned helper is checked: apps/desktop/resources/bin is gitignored, so a binary prepared before this change is still in developers' trees and would otherwise be packaged unnoticed. The provenance record becomes a single-executor record, and its test asserts the manifest pins no executor the record does not account for.

maka-cu is the executor that runs (#1953, #1958), so the third-party one it replaced has no caller left. This deletes the cua-driver backend, service, snapshot, page-target, result and release modules with their tests, the preparation and bundle-check scripts, its vendored notice, its manifest entry and its artifact-integrity document. Shared modules stay: stdio-json-rpc, frame-budget, display-snapshot and abortable-delay are used by maka-cu. Nothing is renamed — CuaSessionState, CuaFrameState and CuaBoundAction describe sessions and frames, not the executor. The selector, the capability card and the boot wiring collapse to one executor. The selector loses the union and its two overloads; the health function reads one snapshot instead of reconciling an action/capture role pair; boot reads executorState directly rather than falling back from a serviceState that no longer exists anywhere. Two fixes travel with it. The process-restart soak still called backend.serviceState(), which maka-cu does not expose, so it threw a TypeError on round 1 inside the try — after the real work had succeeded — and wrote up a passing real-machine run as a failure; it now reads executorState() and compares one generation. A new scripts/cu-process-restart-harness.test.mjs reads the harness's own source for the backend methods it calls and asks a real backend whether they exist, so the next such drift fails in CI rather than on a real machine. verify-macos-arm64-dmg keeps forbidding both cua-driver paths, and macos-arm64-release.test.mjs now asserts every unsigned helper is checked: apps/desktop/resources/bin is gitignored, so a binary prepared before this change is still in developers' trees and would otherwise be packaged unnoticed. The provenance record becomes a single-executor record, and its test asserts the manifest pins no executor the record does not account for.

hqhq1025 · 2026-08-03T07:23:33Z

This pull request is the second link in a three-part chain and its base is
pull request 1953, feat(computer-use): add maka-cu as a selectable executor
backend. The chain has to merge in order, because after the third link main
has no other executor.

What changes for a user

Computer Use now runs on maka-cu. Before this, maka-cu existed in the tree and
was reachable only by a caller that named it, and nothing named it, so
cua-driver was still the executor doing the work. This flips the default and
points the desktop host at it, which is the whole of the behaviour change.

Concretely: DEFAULT_CU_BACKEND_ID becomes maka-cu, and cua-driver is now
reached only by naming it, which its type makes mandatory. The selector's
branch is rewritten at the same time, because it tested deps.backendId ===
'maka-cu' rather than the resolved id: flipping the constant on its own would
have constructed a cua-driver backend and reported it as maka-cu, which is the
worst of both outcomes. The desktop host reads the makaCu entry of
bundled-tools.json, verifies resources/bin/maka-cu against the digest pinned
there, and deliberately asks for no backend id at all, so that "which executor
ships" stays one decision recorded in one place rather than a default and a
host that can quietly disagree about it. The host's health reporter collapses
from a pair of roles to a single state, because maka-cu supervises one child
rather than an action process and a capture process.

What is not changing yet

Synthetic keyboard and coordinate dispatch still fail closed.
allowCompatibilityInputDispatch stays off, so type, key, press_key and every
coordinate action are refused with the sentence that names the actions which do
work. Turning that on is a policy decision with its own argument to make and it
belongs in its own change.

maka-cu is still unsigned and still not distributed. Its distributionReady is
false and the DMG verifier still forbids its path in a packaged build, so a
packaged build continues to select no executor at all. This default takes
effect in a development build.

No tool schema changes. The model-facing surface, the observation format and
the approval classes are exactly what they were.

On the type widenings PR 1953 flagged

MakaCuObservation, MakaCuSemanticAction, MakaCuBackend and their neighbours stay
local to @maka/computer-use. This is not the change that should move them into
@maka/runtime. The reason those declarations are local is that
CuObservation and CuSemanticAction are the shared model-facing contract, and
widening them would add window_action, scroll_element and an element-targeted
press_key to a contract no tool schema can produce, plus observation fields no
tool renders. Moving the declarations up is only defensible together with the
tool layer that renders those fields and the wire schemas that produce those
actions. This change adds neither. It belongs in the change that makes the tool
surface read truncated, query, menu, obscuringRects and the per-element
subrole, placeholder and advertised actions, and that gives window_action and
scroll_element a wire schema. Until then, keeping them local costs nothing:
MakaCuObservation structurally is a CuObservation, so nothing downstream sees a
difference, and this package's own tests cover the extra branches.

Verification

npm --workspace @maka/computer-use run build and run test both pass.
npm run test:scripts, npm run format:check, npm run lint and
node scripts/check-console.mjs all pass. npm --workspace @maka/desktop run
build:main reports the same two pre-existing errors on this machine as it does
on the base branch, both from @maka/ui failing to build for an unrelated reason
here; the delta is zero and every main-process file in this change typechecks.
The desktop Computer Use host, tool-assembly and model-tools tests pass.
EOF

hqhq1025 · 2026-08-03T09:47:50Z

Rebased only, no content change on this branch. Its base #1953 was rebased onto current main so that the chain picks up computer-use-schema-parity — the old merge base was one commit before that test landed — and this branch was replayed onto the new #1953 head with no conflicts. #1959 was then replayed onto this one, also cleanly.

Nothing here was edited. Flagging it so the force-push is not read as a content change.

The previous change added maka-cu next to cua-driver and left it unreachable unless a caller named it. Nothing named it, so nothing ran it. This flips the default and points the desktop host at it, which is the whole of the behaviour change. DEFAULT_CU_BACKEND_ID becomes maka-cu, and the selector's branch is rewritten so the default is the thing that routes rather than only the thing that gets reported: it read deps.backendId === 'maka-cu', so flipping the constant alone would have labelled a cua-driver backend 'maka-cu'. cua-driver is now reached by naming it, and naming it is required by its type. The desktop host reads the makaCu entry of bundled-tools.json, verifies resources/bin/maka-cu against the digest pinned there, and asks for no backend id at all so that "which executor ships" stays one decision in one place. Its health reporter collapses from a pair of roles to one state, because maka-cu supervises one child. Not changing yet: synthetic keyboard and coordinate dispatch still fail closed, and maka-cu is still unsigned and still not distributed, so a packaged build continues to select no executor.

maka-cu is the executor that runs (apache#1953, apache#1958), so the third-party one it replaced has no caller left. This deletes the cua-driver backend, service, snapshot, page-target, result and release modules with their tests, the preparation and bundle-check scripts, its vendored notice, its manifest entry and its artifact-integrity document. Shared modules stay: stdio-json-rpc, frame-budget, display-snapshot and abortable-delay are used by maka-cu. Nothing is renamed — CuaSessionState, CuaFrameState and CuaBoundAction describe sessions and frames, not the executor. The selector, the capability card and the boot wiring collapse to one executor. The selector loses the union and its two overloads; the health function reads one snapshot instead of reconciling an action/capture role pair; boot reads executorState directly rather than falling back from a serviceState that no longer exists anywhere. Two fixes travel with it. The process-restart soak still called backend.serviceState(), which maka-cu does not expose, so it threw a TypeError on round 1 inside the try — after the real work had succeeded — and wrote up a passing real-machine run as a failure; it now reads executorState() and compares one generation. A new scripts/cu-process-restart-harness.test.mjs reads the harness's own source for the backend methods it calls and asks a real backend whether they exist, so the next such drift fails in CI rather than on a real machine. verify-macos-arm64-dmg keeps forbidding both cua-driver paths, and macos-arm64-release.test.mjs now asserts every unsigned helper is checked: apps/desktop/resources/bin is gitignored, so a binary prepared before this change is still in developers' trees and would otherwise be packaged unnoticed. The provenance record becomes a single-executor record, and its test asserts the manifest pins no executor the record does not account for.

maka-cu is the executor that runs (#1953, #1958), so the third-party one it replaced has no caller left. This deletes the cua-driver backend, service, snapshot, page-target, result and release modules with their tests, the preparation and bundle-check scripts, its vendored notice, its manifest entry and its artifact-integrity document. Shared modules stay: stdio-json-rpc, frame-budget, display-snapshot and abortable-delay are used by maka-cu. Nothing is renamed — CuaSessionState, CuaFrameState and CuaBoundAction describe sessions and frames, not the executor. The selector, the capability card and the boot wiring collapse to one executor. The selector loses the union and its two overloads; the health function reads one snapshot instead of reconciling an action/capture role pair; boot reads executorState directly rather than falling back from a serviceState that no longer exists anywhere. Two fixes travel with it. The process-restart soak still called backend.serviceState(), which maka-cu does not expose, so it threw a TypeError on round 1 inside the try — after the real work had succeeded — and wrote up a passing real-machine run as a failure; it now reads executorState() and compares one generation. A new scripts/cu-process-restart-harness.test.mjs reads the harness's own source for the backend methods it calls and asks a real backend whether they exist, so the next such drift fails in CI rather than on a real machine. verify-macos-arm64-dmg keeps forbidding both cua-driver paths, and macos-arm64-release.test.mjs now asserts every unsigned helper is checked: apps/desktop/resources/bin is gitignored, so a binary prepared before this change is still in developers' trees and would otherwise be packaged unnoticed. The provenance record becomes a single-executor record, and its test asserts the manifest pins no executor the record does not account for.

hqhq1025 · 2026-08-03T07:23:33Z

This pull request is the second link in a three-part chain and its base is
pull request 1953, feat(computer-use): add maka-cu as a selectable executor
backend. The chain has to merge in order, because after the third link main
has no other executor.

What changes for a user

Computer Use now runs on maka-cu. Before this, maka-cu existed in the tree and
was reachable only by a caller that named it, and nothing named it, so
cua-driver was still the executor doing the work. This flips the default and
points the desktop host at it, which is the whole of the behaviour change.

Concretely: DEFAULT_CU_BACKEND_ID becomes maka-cu, and cua-driver is now
reached only by naming it, which its type makes mandatory. The selector's
branch is rewritten at the same time, because it tested deps.backendId ===
'maka-cu' rather than the resolved id: flipping the constant on its own would
have constructed a cua-driver backend and reported it as maka-cu, which is the
worst of both outcomes. The desktop host reads the makaCu entry of
bundled-tools.json, verifies resources/bin/maka-cu against the digest pinned
there, and deliberately asks for no backend id at all, so that "which executor
ships" stays one decision recorded in one place rather than a default and a
host that can quietly disagree about it. The host's health reporter collapses
from a pair of roles to a single state, because maka-cu supervises one child
rather than an action process and a capture process.

What is not changing yet

Synthetic keyboard and coordinate dispatch still fail closed.
allowCompatibilityInputDispatch stays off, so type, key, press_key and every
coordinate action are refused with the sentence that names the actions which do
work. Turning that on is a policy decision with its own argument to make and it
belongs in its own change.

maka-cu is still unsigned and still not distributed. Its distributionReady is
false and the DMG verifier still forbids its path in a packaged build, so a
packaged build continues to select no executor at all. This default takes
effect in a development build.

No tool schema changes. The model-facing surface, the observation format and
the approval classes are exactly what they were.

On the type widenings PR 1953 flagged

MakaCuObservation, MakaCuSemanticAction, MakaCuBackend and their neighbours stay
local to @maka/computer-use. This is not the change that should move them into
@maka/runtime. The reason those declarations are local is that
CuObservation and CuSemanticAction are the shared model-facing contract, and
widening them would add window_action, scroll_element and an element-targeted
press_key to a contract no tool schema can produce, plus observation fields no
tool renders. Moving the declarations up is only defensible together with the
tool layer that renders those fields and the wire schemas that produce those
actions. This change adds neither. It belongs in the change that makes the tool
surface read truncated, query, menu, obscuringRects and the per-element
subrole, placeholder and advertised actions, and that gives window_action and
scroll_element a wire schema. Until then, keeping them local costs nothing:
MakaCuObservation structurally is a CuObservation, so nothing downstream sees a
difference, and this package's own tests cover the extra branches.

Verification

npm --workspace @maka/computer-use run build and run test both pass.
npm run test:scripts, npm run format:check, npm run lint and
node scripts/check-console.mjs all pass. npm --workspace @maka/desktop run
build:main reports the same two pre-existing errors on this machine as it does
on the base branch, both from @maka/ui failing to build for an unrelated reason
here; the delta is zero and every main-process file in this change typechecks.
The desktop Computer Use host, tool-assembly and model-tools tests pass.
EOF

hqhq1025 · 2026-08-03T09:47:50Z

Rebased only, no content change on this branch. Its base #1953 was rebased onto current main so that the chain picks up computer-use-schema-parity — the old merge base was one commit before that test landed — and this branch was replayed onto the new #1953 head with no conflicts. #1959 was then replayed onto this one, also cleanly.

Nothing here was edited. Flagging it so the force-push is not read as a content change.

The previous change added maka-cu next to cua-driver and left it unreachable unless a caller named it. Nothing named it, so nothing ran it. This flips the default and points the desktop host at it, which is the whole of the behaviour change. DEFAULT_CU_BACKEND_ID becomes maka-cu, and the selector's branch is rewritten so the default is the thing that routes rather than only the thing that gets reported: it read deps.backendId === 'maka-cu', so flipping the constant alone would have labelled a cua-driver backend 'maka-cu'. cua-driver is now reached by naming it, and naming it is required by its type. The desktop host reads the makaCu entry of bundled-tools.json, verifies resources/bin/maka-cu against the digest pinned there, and asks for no backend id at all so that "which executor ships" stays one decision in one place. Its health reporter collapses from a pair of roles to one state, because maka-cu supervises one child. Not changing yet: synthetic keyboard and coordinate dispatch still fail closed, and maka-cu is still unsigned and still not distributed, so a packaged build continues to select no executor.

maka-cu is the executor that runs (apache#1953, apache#1958), so the third-party one it replaced has no caller left. This deletes the cua-driver backend, service, snapshot, page-target, result and release modules with their tests, the preparation and bundle-check scripts, its vendored notice, its manifest entry and its artifact-integrity document. Shared modules stay: stdio-json-rpc, frame-budget, display-snapshot and abortable-delay are used by maka-cu. Nothing is renamed — CuaSessionState, CuaFrameState and CuaBoundAction describe sessions and frames, not the executor. The selector, the capability card and the boot wiring collapse to one executor. The selector loses the union and its two overloads; the health function reads one snapshot instead of reconciling an action/capture role pair; boot reads executorState directly rather than falling back from a serviceState that no longer exists anywhere. Two fixes travel with it. The process-restart soak still called backend.serviceState(), which maka-cu does not expose, so it threw a TypeError on round 1 inside the try — after the real work had succeeded — and wrote up a passing real-machine run as a failure; it now reads executorState() and compares one generation. A new scripts/cu-process-restart-harness.test.mjs reads the harness's own source for the backend methods it calls and asks a real backend whether they exist, so the next such drift fails in CI rather than on a real machine. verify-macos-arm64-dmg keeps forbidding both cua-driver paths, and macos-arm64-release.test.mjs now asserts every unsigned helper is checked: apps/desktop/resources/bin is gitignored, so a binary prepared before this change is still in developers' trees and would otherwise be packaged unnoticed. The provenance record becomes a single-executor record, and its test asserts the manifest pins no executor the record does not account for.

maka-cu is the executor that runs (#1953, #1958), so the third-party one it replaced has no caller left. This deletes the cua-driver backend, service, snapshot, page-target, result and release modules with their tests, the preparation and bundle-check scripts, its vendored notice, its manifest entry and its artifact-integrity document. Shared modules stay: stdio-json-rpc, frame-budget, display-snapshot and abortable-delay are used by maka-cu. Nothing is renamed — CuaSessionState, CuaFrameState and CuaBoundAction describe sessions and frames, not the executor. The selector, the capability card and the boot wiring collapse to one executor. The selector loses the union and its two overloads; the health function reads one snapshot instead of reconciling an action/capture role pair; boot reads executorState directly rather than falling back from a serviceState that no longer exists anywhere. Two fixes travel with it. The process-restart soak still called backend.serviceState(), which maka-cu does not expose, so it threw a TypeError on round 1 inside the try — after the real work had succeeded — and wrote up a passing real-machine run as a failure; it now reads executorState() and compares one generation. A new scripts/cu-process-restart-harness.test.mjs reads the harness's own source for the backend methods it calls and asks a real backend whether they exist, so the next such drift fails in CI rather than on a real machine. verify-macos-arm64-dmg keeps forbidding both cua-driver paths, and macos-arm64-release.test.mjs now asserts every unsigned helper is checked: apps/desktop/resources/bin is gitignored, so a binary prepared before this change is still in developers' trees and would otherwise be packaged unnoticed. The provenance record becomes a single-executor record, and its test asserts the manifest pins no executor the record does not account for.

hqhq1025 force-pushed the pr/maka-cu-backend branch from 29684a0 to e4d2442Compare August 3, 2026 09:29

hqhq1025 force-pushed the pr/maka-cu-default branch from d83c516 to 11ffd6dCompare August 3, 2026 09:30

hqhq1025 mentioned this pull request Aug 3, 2026
chore(computer-use): remove cua-driver #1959
Merged

hqhq1025 changed the base branch from pr/maka-cu-backend to mainAugust 3, 2026 11:27

hqhq1025 force-pushed the pr/maka-cu-default branch 3 times, most recently from 40c225e to d048398Compare August 3, 2026 12:39

hqhq1025 force-pushed the pr/maka-cu-default branch from d048398 to d4195e9Compare August 3, 2026 14:09

hqhq1025 merged commit 3793cc0 into mainAug 3, 2026
9 of 11 checks passed