Orca v0.5.14

Orca v0.5.14

Changes since v0.5.13:

• Computer use asks before observing or operating a window you already had
  open. Allow it once or for the session, or deny it and let Orca open its
  own. App grants do not cover your windows; full-auto skips window approval.
• list_apps shows window titles only for apps used this session. The driver
  never uses the desktop and checks that input reaches the selected window.
• Usable-window lists, clearer errors, windowless shortcuts and window-raising
  recovery reduce failed actions. Three consecutive failures add a hint to
  stop and report; six stop that app for the rest of the turn.
• App session grants now appear in the real TUI. MCP approvals are not resumed
  after a restart; turn-only tool approvals are refused unless the same tool
  definition can be restored. Late queue updates no longer revive finished
  turns, and flaky tests use controlled synchronization.
• A developer acceptance harness checks 15 real tasks independently. In the
  third live acceptance attempt, neither run used a pre-existing window
  without approval; single-step results were 8/8 twice, multi-step 6/7 and 7/7.

Changes

Your windows and approvals

Before the first computer call for each user message, Orca records the
windows already open across running apps, including tray apps and minimized
or off-screen windows. Those windows are yours unless Orca opened them
earlier in the session. Windows that appear during the turn count as Orca's
and remain its own for the session when the end-of-turn snapshot records them.
If that snapshot fails or the driver resets mid-turn, those windows count as
yours next turn. Outside full-auto, a failed initial snapshot refuses the
call instead of assuming the windows belong to Orca.

Outside full-auto, a call that names or inherits one of your windows asks
about that window. The preview names the action, escaped window title, app
and bundle id. Its approval target is bundle#window:<id>, or
bundle#window:<id>#secure for password entry. The ordinary window panel offers:

• 1 Allow this window once: run this call; later calls ask again.
• 2 Allow this window this session: allow that window until you quit.
• 4 Deny: keep the window to yourself and let the turn continue, so
  Orca can open its own window instead.

Press 4 (Deny) to keep the window and let Orca continue. Esc can stop the
whole turn instead: once a computer call has run in the turn, Orca's Esc
listener stops the turn even while this panel is open. App, password-entry
and other tool denials still stop the turn. Window panels offer no saved
grant because window ids do not last across sessions. They offer no all-app grant because each of your
windows needs its own approval.

Outside full-auto, app, wildcard and whole-tool allow rules never authorize
an existing-window target. Only an exact allow for bundle#window:<id> does,
including the panel's session grant. App deny and prompt rules still cover
its windows; window deny and prompt rules also cover password entry in that
window. Outside full-auto, no window grant or allow rule preapproves password
entry in your window.

In full-auto, Orca does not ask about windows. Password entry uses the
ordinary bundle#secure target: it still asks unless a whole-tool computer
allow rule without a pattern preapproves it for an app that does not run
commands. Window deny and prompt rules (bundle#window:<id>) do not apply
there; app deny and prompt rules still apply.

list_apps shows window ids and titles only for apps Orca has used in this
session, marking your windows (yours) and minimized ones (minimized).
Unused apps show their name, bundle id, process id and window count. Candidate
app lists in errors follow the same title restriction. Using an app can
therefore reveal titles of its other windows to the model even before those
windows are approved for observation or input.

Window selection and input

Observe and act use only layer-0 windows. The desktop, menus and floating
panels are never selected, even when explicitly named. An omitted window
does not default to one of your unapproved windows; if those are the only
usable windows, the error explains how to request one or open another.
Refusal messages omit untitled off-screen helper windows.

Accessibility windows are matched to capture windows by CGWindowID, so two
Chrome windows at the same position and size remain distinguishable. Frame
matching is a fallback only when the id cannot be read; ambiguous matches
with an unapproved window are refused.

Typing and keys, including element-targeted typing, must reach the selected
window. Coordinate clicks must hit that window too. If background delivery
would reach another window, Orca takes the foreground path and raises the
selected window first, or refuses when foreground switching is disabled.

A lone Cmd+N, with no other modifier and no window specified, can reach an
app whose usable windows are all yours, including when Accessibility cannot
see them. It also works when Finder shows only its desktop. Other shortcuts
cannot use this exception. Cmd+Q, Cmd+Option+Q (Quit and Keep Windows),
Cmd+Option+W (Close All), Cmd+Option+M (Minimize All) and Cmd+H (Hide)
are refused while the app has any of your windows that the call is not approved to use;
full-auto does not impose that window restriction.

launch_app with open can place a file or URL in an existing window, for
example as a browser tab. When the app has your windows and the launch
returns only those windows, the result notes that the content may have
landed there and that Orca has not viewed it.

Reliability and recovery

list_apps and launch_app list only windows that are layer 0, match an
Accessibility window, and are either on screen (standard windows, dialogs
or document-sized windows) or minimized. Minimized windows carry a label.
Accessibility checks have a bounded timeout; an app that does not answer falls back to visible
document-sized windows, which observe may still refuse. Without a window id,
Orca prefers a usable main window, then another usable window, subject to your
approvals.

Errors distinguish an unusable window id, a window not yet observed, a window
that changed after observation, and an app that has no window yet. Each gives
a next step. A closed window inherited from the last observation is forgotten
and resolution is retried once; an already delivered action is not repeated
just because its follow-up observation fails.

For an app with no Accessibility windows, a Command or Control shortcut or
Escape can be sent without a window, using the foreground path. Text-entering
keys are refused. The driver checks again after activation so a newly appeared
window does not receive unobserved input. Apps with only desktop or floating
windows allow only the lone Cmd+N exception above. System-hosted Open panels
are not directly observable; Cmd+N or launch_app with open provides a way
to create a usable window.

When AXRaise fails, Orca continues only if the selected window is already the
app's focused window. Otherwise it retries the raise once. Foreground, cover
and input-recipient checks still apply. Common key spellings such as
shift+right are accepted, and key-format errors show a valid example.
The tool guidance keeps work in an app the user names and directs app launches
through launch_app, rather than sandbox-blocked shell open or osascript.

Failures are counted per app within one user turn. The third consecutive
failure adds a stop-and-report hint; the sixth stops computer use on that
app for the rest of the turn, before further driver requests or approval
panels. Validation failures and timeouts count; cancellations, approval
denials and list_apps do not. A success resets the count, as does the next
user message. Other apps remain available.

App grants, approval recovery and runtime

The real TUI now offers Allow this app this session, Allow all apps
this session, and the saved variants when appropriate, rather than showing
only Allow once and Deny. Terminal and IDE approvals retain their app-specific
options, and password entry retains its once-only choice. Existing-window
panels use the narrower options described above.

Approvals waiting on MCP tools or tools supplied only to the executing turn
remain answerable while that turn is alive. MCP approvals are not resumed
after a restart because their definitions can change on reconnect. Turn-only
tool approvals are also refused unless Orca can restore the same definition.
Older saved tool-approval continuations without that proof are refused.
Reopening a session does not silently authorize a changed or missing tool.

TUI, ACP and server tool requests use the executing session or turn's tool
definitions for action classification, including writable MCP and shell-like
external tools. Requested-tool events name MCP resources as server:uri,
skills by their id argument (usually the skill directory name), and
workflows by script path, name or draft id. Inline workflow code does not
match pattern-based permission rules, including wildcards;
whole-tool rules keep their existing scope.

Custom-agent definitions are fixed at the session's first turn. Later edits
take effect in a new session. Delegation and workflow guidance is shorter: the
measured first request in a plain directory fell from 33,342 to 28,170
characters; a supplied real-API run used 7,077 prompt tokens, compared with
8,094 after v0.5.13's changes.

Built-in prices, peak-hour rules and the pricing verification date remain
unchanged from v0.5.13 (2026-10-20). ORCA_PRICING_URL=off now disables
background price refresh in any build. Repository Cargo processes set it so
tests stay offline; installed releases retain their normal refresh behavior.

TUI and test reliability

A late queue snapshot can no longer mark a finished or cancelled turn as
running again. The TUI returns to idle instead of keeping its spinner active,
and idle Ctrl-C can exit normally.

Flaky runtime, TUI, workflow and tools tests now synchronize with the state
they check: complete terminal frames, workflow startup or pause transitions,
and persistence failures held through recovery assertions. Fixtures share
the right process home, isolate injected failures between test threads and
close shell stdin. Workflow startup tests accept either an immediate failure
or a later recorded failure after background launch. The Esc-listener control
allows cold native startup without relaxing its stop-latency assertion.

Developer acceptance harness and documentation

scripts/eval/computer_use/ runs eight single-step and seven multi-step
tasks, one at a time in fresh Orca TUIs. It checks files, Accessibility state,
form logs or task-window OCR independently of the model's answer. Fixtures,
preflight checks, task-provided window approvals and cleanup keep runs scoped;
incomplete cleanup stops the suite. Reports include time, calls, errors,
approvals, token cost and comparison with a baseline.

The harness records unapproved use of pre-existing windows per call, including
requested, observed and inherited windows, and separately counts calls whose
window cannot be attributed. An action's own observation counts as GUI
evidence. Its mock dry run is developer tooling, not live product acceptance.

English and Chinese guides and READMEs now explain the window boundary,
approval choices, Esc behavior, permission-rule targets and recovery limits.

Compatibility

• Existing app rules. Outside full-auto, rules and session grants
  written for apps do not authorize your existing windows. Approve each
  window once or for the session.
• Driver protocol 3. Reliability moved the protocol from 1 to 2; the
  window boundary moves it to 3. The driver ships inside the same Orca binary,
  so there is no separate driver to install. If Orca is updated during a
  session, start a new session when the handshake requests it.
• Known window limits. Windows you open after the turn's first computer-use
  step count as Orca's, as do windows restored when Orca launches an app.
  Reusing a closed window for a new document (Preview, for example) can cause
  another approval. A changed window id also needs a new approval.
• Cmd+N and opened content. Some apps use Cmd+N for something other than
  New Window; it can act inside your front window, and the result says when
  no new window appeared. Opening a URL or file can reuse your window too.
• Remaining follow-ups. Finder's Empty Trash shortcuts still need a
  destructive-shortcut policy. A windowless Chrome still accepts reopen-tab
  shortcuts. Window-denial continuation also applies to denials synthesized
  when no client can answer. The harness's preflight does not list desktop-layer
  windows, so its window-touch metric alone cannot prove the desktop was not
  read; the live sessions below were also inspected by hand. Interrupted
  runtime subagent-worker tests can leave busy-loop descendants behind.
• Platforms and pricing. Computer use remains limited to macOS 14 or later
  in the interactive TUI's main session. Pricing and its built-in verification
  date are unchanged; no new pricing check is claimed for this release.

Verification

• PR CI: all checks for PR #145, #146, #147, #148, #149 and #150 passed.

• Real-Mac workspace run, 2026-10-26: macOS 26.6.2 on Apple Silicon, Rust
  1.95.0, at 52d7a7ee (the window-boundary code before the release commits):

  • cargo nextest run --workspace --all-targets --locked --profile ci --no-fail-fast:
    4632 passed, 106 skipped.
  • cargo nextest run -p orca-tui --lib --locked --profile ci-serial --retries 0:
    1829 passed, 24 skipped.

• Live acceptance, attempt 3 at 5179b44d:

  Result	Run 1	Run 2
  Unapproved use of a pre-existing window	0	0
  Desktop or non-document windows observed (manual session review)	0	0
  Single-step tasks	8/8	8/8
  Multi-step tasks	6/7	7/7
  Tool errors	14	13

  The remaining miss was Finder folder renaming in M3, run 1. Orca asked
  about the user's out window, accepted Deny, opened its own with Cmd+N and
  created reports, then failed to rename the folder and tried TextEdit,
  which the harness counted as a task-scope violation. M3 therefore did not
  meet the spec's two-run success criterion. The first two acceptance attempts
  found boundary and harness issues that were fixed before attempt 3. The
  refusal of Cmd+Option+Q and Cmd+H came after these runs; unit tests cover it.

• Live driver suite: 95/96. The failure in a_point_on_the_button_presses_it
  came from macOS refusing to reactivate the terminal while the test restored
  the GUI; it is unrelated to this release.

Local release-preparation checks, on the same Mac:

• cargo update --workspace --offline changed only the workspace package's
  version in Cargo.lock; dependency versions are unchanged.
• Version sync reported 0.5.14, and the npm launcher contract passed (5 tests).
• cargo test -p orca-computer-use --lib --locked: 286 passed.
• cargo test -p orca-runtime --lib --locked computer_use: 86 passed, 2 ignored.
• cargo test -p blade-deepseek --test public_docs_contract --test pricing_contract --locked:
  14 public-docs and 6 pricing contracts passed.
• cargo clippy --workspace --all-targets --locked passed with no errors. One
  warning falls on a line this release changed: a needless_borrow that
  follows the pattern of the code around it.
• cargo fmt --all -- --check, the four boundary validators, the live-test
  build, the 72 acceptance-harness unit tests, npm run build and
  npm run check:seo in site/, and git diff --check passed.

Upgrade

After v0.5.14 is published:

npm install -g @blade-ai/orca@0.5.14
orca --version

The protocol-3 computer-use driver is part of the same binary; no separate
upgrade step is needed. Outside full-auto, app permission rules do not
cover windows: use the window panel to grant access to each existing window
you want Orca to use.