feat(settings): opt in to Code Mode for new tasks

[Astro-Han]

Summary

Add an opt-in Code Mode switch under Settings → General → Task defaults. The selected Runtime Host saves the global default, and newly created tasks persist their tool mode. Changing the switch leaves existing tasks unchanged; copies and child tasks inherit their source task's mode. Scheduled agent tasks also freeze the mode in their execution template, with legacy templates using direct tools. There is no per-task UI switch.

When enabled, the model receives only exec, with the current callable tool catalog in its description. Nested calls use the existing ToolRuntime permission checks, durable settlement, cancellation, and exclusive-tool admission. Tool search refreshes the catalog for the next cell; nested questions and plan/graph handoffs remain available. Denied sandbox tools are removed from the model-visible nested catalog.

Execution boundary

Keep @ai-sdk/code-mode, upgrading 1.0.42 → 1.0.56 and aligning the AI SDK family and provider-utils patch. Pin its run dependency to 2.1.4 and apply two documented dependency patches: the SDK forwards an opt-in execution-time policy, and the executor enforces it at synchronous QuickJS entry points.

Previously, a 30-second total deadline also aborted normal host-tool and user-input waits. Maka now uses a cumulative 30-second VM execution budget. External waits retain the VM and consume no execution budget; individual Promise completions immediately advance dependent code without a continuation batch or an extra parent-model request. Default SDK wall-time behavior remains available and unchanged.

The executor removes empty-job polling and waits for bridge responses or cancellation. It also uses the Promise handle returned by evaluation directly, removing a guest-writable global result slot. Runtime cancellation still drains started host operations before releasing cell admission. No new Worker pool, replay mechanism, or Runtime scheduling layer is added.

The patched run manifest uses Maka's Node >=22.19 baseline and removes the optional TypeScript peer used by the older-Node fallback. Supported Maka runtimes use native type stripping, so no second compiler is shipped. Attribution, generated notices, and source-header inventory are updated. The large generated patch hunk is the inline Worker with embedded WASM; patches/run-2.1.4-source.diff provides the readable source changes and rebuild instructions are in patches/README.md.

Host protocol compatibility epoch moves from 142 to 143.

Verification

• 292 relevant Runtime tests passed, including dependent Promise.race progress across long waits, cumulative computation across awaits, computation while a host call is pending, cancellation/drain, and resource limits.
• The 58 Code Mode/backend tests also passed on the minimum supported Node 22.19.0.
• 69 scheduled-task and Session catalog tests passed; 196 release checks passed.
• Patched upstream run: 364 tests, build, and typecheck passed.
• A real 31-second host wait crossed the previous default deadline, returned its answer exactly once, and kept its signal live. Independent review also tested a 15-second wait under a 12ms execution budget and cancellation followed by reuse of a single Worker slot.
• Independent clean npm ci, dependency patch application, production dependency inspection, and SDK smoke passed. Execution mode allows a long host wait; default wall mode still times out.
• Real Electron settings test passed: enable/disable persists across reopening, with a screenshot attached to the test result.
• Workspace test build, rebuilt desktop renderer, formatting, lint, license-header checks, and whitespace checks passed.

Two independent Reviewer Deep reviews covered adversarial behavior and simplification. No P0/P1 remains. Removed the old direct-only plan/graph assertions, redundant diagnostics, idle polling, and the mutable global result slot. Retained distinct tests for permissions, cancellation, durable settlement, and execution budgets.

Known limits

Waiting invocations retain their VM and Worker/memory quota until completion or cancellation. This includes guest-created Promises that never settle; Runtime supplies a reachable cancellation signal, and existing admission and process-wide resource limits remain in force. There is no automatic liveness deadline or deadlock detector. Provider-native and explicitly non-nestable tools remain unavailable through Code Mode; execution-time mode supports asynchronous host functions, not synchronous bridge/module-loader calls. These tests establish execution and settings behavior, not a live-model quality improvement.

AI use

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Codex implemented dependency alignment, executor patches, settings/runtime integration, and tests. Two Reviewer Deep agents performed independent reviews.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described above
• No

[jackwener]

Approve at 2fda64d5d310fe33dafb2ebd528606ebfd48d8b9. I found no blocking issues. Opt-in Code Mode is off by default, is frozen per Session at creation, and the execution-budget semantics match what the patch notes describe.

What I actually checked.

• Budget, async and cancellation. In execution mode the budget accumulates only synchronous entries into the sandbox: the measuring wrapper returns immediately when already inside an outer entry, so reentrant calls do not double-count, and the interrupt check compares accumulated time plus the current span against the budget. No wall-clock timer is armed in this mode, which is the documented intent. Cancellation is wired into the existing host cancel/fail path and rejects the race that the resolver awaits, so a cancelled run unblocks without relying on polling.
• Removal of the resolver's polling loop. This is not gated on the new mode, so I checked the default wall path separately: the wall deadline is enforced on the manager side by a timer that fails the run terminally, independent of the worker's await. Removing the per-tick poll therefore does not weaken the default timeout.
• Settlement. The cell's promise drains every host operation it started on both the success and failure paths, looping while new operations appear, so repeated cancellation cannot accumulate unbounded host work. Nested calls now carry a step identity, are refused once the turn has yielded, and route plan and yield results through the same handlers as direct calls.
• Mode freezing. New Sessions read the setting once at creation and store the result on the Session header; turns read that frozen value. Scheduled tasks capture the mode into their execution template at creation, and the stored template is validated on decode, so changing the setting later does not rewrite existing tasks or past jobs.
• Dependency patches and install consistency. The override pinning, the patched package versions and the patch filenames agree with each other. The readable source diff is coherent and corresponds to the described behaviour.
• The large generated hunk. I extracted the embedded WebAssembly payload from both sides of that hunk and compared it directly: it is byte-identical (848,536 base64 characters, identical digest). The entire difference in that line is rebuilt worker JavaScript, which confirms the patch notes' claim that the embedded binary is unchanged.

Two non-blocking observations.

1. In this mode the tool plan returns no context-budget diagnostics at all, while the single callable tool's description now embeds the full serialized catalog. The catalog still costs prompt space, but nothing reports it, so a Session in this mode loses the visibility that other Sessions keep. Consider reporting the projected tool's schema size rather than suppressing the diagnostic.
2. The rebuilt worker bundle is minified, so its difference is dominated by renamed local identifiers. Beyond the binary-identity check above, that hunk is not reviewable by reading; its provenance rests on the documented rebuild procedure and the pinned upstream commit. That procedure being written down is what makes this reviewable at all, and it is worth keeping accurate.

What I did not verify. I reviewed code and hosted check results only. I did not run the test suite, a build, an end-to-end run or any sandbox execution, so I did not measure real budget accounting, cancellation timing or memory behaviour. The no-polling change assumes the guest environment exposes no timers, so that nothing becomes runnable without a bridge response; that holds for the frozen guest surface in this diff, but I did not audit the whole upstream guest environment for a timer. This change also raises eight SDK package versions alongside the feature; I did not assess those upgrades independently, and hosted checks are the only evidence for them here. All required checks are terminal on this commit: seventeen successful and one skipped, with none failing or pending.

---

Automated review notice. This review was produced by an automated reviewer (agent seat kabi-opus, model Claude Opus) acting on its own review identity. It is posted from a shared machine account, so the seat is named here because the account alone does not identify the reviewer. It is not an independent human review and does not substitute for one. Its scope and limits are stated above; no merge was performed.