mirror of
https://github.com/stablyai/orca.git
synced 2026-11-02 01:57:57 +00:00
3d812eb9bf54c39e80098bb6ce55f8498a3d3c8c
9
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
d58ab9762c |
perf(memory): read macOS footprints with a bundled proc_pid_rusage helper instead of top (#34053)
top costs ~263 ms of CPU per sample, so the memory panel only refreshed footprints every 10 s. The new orca-process-footprint helper reads phys_footprint for every same-user process in ~3 ms, so footprints now refresh on the panel's 2 s poll. top stays as the fallback when the helper is missing or fails. Co-authored-by: m4air <m4air@Mac.localdomain> |
||
|
|
7909732283 |
perf(claude): run the Windows Claude hook as a signed native claude-hook.exe (#27719)
* perf(claude): run the Windows Claude hook as a native orca-hook.exe
Each Claude hook event on Windows started cmd.exe (plus the user's cmd
AutoRun) and then curl.exe on top of the agent's own shell. A small signed
Rust binary now does the same synchronous POST in one process, under Git
Bash, PowerShell and direct CreateProcess alike.
- native/windows-agent-hook: std-only crate, same contract as the .cmd hook
(prints {}, env guards before stdin, endpoint re-read, 0.5s/1.5s caps,
waits for the listener reply, always exit 0). Its installed file name
selects the agent profile, so the registration stays a bare path.
- Packaged as resources/bin/orca-hook.exe (SignPath signs it with the other
inner PEs); afterPack fails on a missing or wrong-machine binary.
- Claude install copies it verbatim to ~/.orca/agent-hooks/claude-hook.exe
(temp + rename, running copy moved aside) and registers it; it falls back
to the .cmd hook when the bundle is missing, unsigned or cannot be copied.
Only Claude opts in, via windowsNativeHookExecutable.
- The managed-command matcher sweeps .exe entries alongside .cmd/.ps1/.sh.
- The CLI launcher and hook builds share windows-rust-executable-build.mjs,
which now also checks the PE machine.
Refs #20913
* fix(build): publish native Windows binaries atomically so parallel builds cannot collide
The Windows CI lane runs every orca-hook.exe suite in one vitest
invocation, each building through build-windows-agent-hook.mjs. The build
copied straight onto native/windows-agent-hook/.build/orca-hook.exe, and
CopyFile opens its destination unshared, so a second build (or a scanner
still holding the fresh image) failed with EBUSY.
- windows-rust-executable-build.mjs skips the publish when the output
already has the built bytes, otherwise stages a per-process temp file and
renames it over the output, retrying briefly while another handle holds it.
- The test fixture hands each suite a private copy of the build output, so
no suite reads or starts the shared file while another build replaces it.
Refs #20913
* refactor(claude): simplify the native Windows hook to one Claude binary
Review follow-up on the native hook (#20913): the same behaviour with less
machinery.
- The binary is built, shipped and installed as claude-hook.exe, so the
installed name matches its PE OriginalFilename. It is Claude-only, so the
file-name profile table and the per-agent opt-in flag are gone; the
registration is gated by the existing Claude-only usesWindowsEntry check.
- Install and refresh reuse writeManagedScript / refreshManagedScriptIfPresent
(now accepting bytes): temp file, rename, skip when identical. A copy whose
hook is still running cannot be replaced; install then registers the .cmd
hook and refresh keeps the old build until a later start, instead of the
rename-aside and *.retired sweep.
- The install-time Authenticode-presence check is dropped. Release CI now
requires resources\bin\claude-hook.exe to be signed (release-cut and the
signing rehearsal), next to resources\bin\orca.exe.
- getStatus counts either Windows form through findManagedEventHookForms in
hook-settings.ts, replacing managed-event-hook-status.ts.
- Rust: plain Claude constants, one endpoint-file lookup (last assignment
wins, as under `call`), one request write and a deadline-bounded drain.
Guard order and form encoding are unchanged.
- Build: PR CI builds the hook once before the Windows tests, so the suites
only read it; the launcher publish goes back to copyFileSync and the retry
loop and its test are gone. The PE-machine check lives only in afterPack.
Cargo.lock joins both crates' build fingerprints, and the launcher's alias
exports are removed.
Refs #20913
* test(ci): run the managed hook stdin-lifecycle suite in the Windows lane
Its claude-hook.exe case (and the other Windows-only cases) are gated per
test, so the lane-registration guard did not require the file and it ran
only on Linux, where those cases skip. Register it in both Windows lists.
Refs #20913
* feat(agent-hooks): ship the native hook as orca-agent-hook.exe <agent>
The native Windows hook (#20913) becomes one general binary that stays
Claude-only in behaviour.
- Named orca-agent-hook.exe everywhere: build output, PE OriginalFilename
and InternalName, resources\bin, the afterPack check, the installed copy
in ~/.orca/agent-hooks, and the release signed-target lists.
- It takes the agent as its first argument and Claude registers
`<path> claude`. The CLAUDE_JOB_DIR exit and the Grok/Devin drain belong
to that agent; an unknown or missing agent answers {} without reading
stdin. The managed-command matcher owns `orca-agent-hook.exe claude` and
still owns the old claude-hook.exe entry, so installs migrate; install
deletes a leftover claude-hook.exe when nothing runs it.
- A copy still running from the previous build no longer forces the .cmd
fallback. Identical bytes are not rewritten; otherwise the temp file is
renamed over the target, and when Windows refuses because the image is
mapped, the running copy is renamed to orca-agent-hook.exe.old first.
Install deletes a stale .old; only when that copy is also still running
does the install fall back to .cmd. writeManagedScript and
refreshManagedScriptIfPresent take the aside path, sharing one helper.
Refs #20913
* fix(agent-hooks): roll back a failed aside rename and keep an installed hook exe
Design-review follow-up on the native hook (#20913).
- If the running copy was moved to orca-agent-hook.exe.old but the new
file then could not take its name, the copy is renamed back before the
error is rethrown, so settings.json never points at a missing exe. The
rename helper now owns the `.old` name, next to the comment that
explains it; a mocked-fs unit test covers both the sync and async paths.
- A failed write, or a build with no bundled exe, keeps registering a copy
that is already installed (every build knows `claude`), so a dev checkout
and an installed build no longer flip settings.json between forms.
- The claude-hook.exe migration is gone: no release ever shipped that
name, so the legacy sweep, the `.exe` matcher needle and their test are
removed.
Refs #20913
* fix(agent-hooks): derive the native hook's agent with win32 path rules
getWindowsNativeHookAgent took the host's basename of the managed script
path, so on a POSIX host (Linux CI) a Windows path was not split and the
registered command became `orca-agent-hook.exe C:\...\claude`. It now takes
the path and applies path.win32.basename itself. The install destination
and the `.old` aside stay on host paths: they name files the host opens.
Refs #20913
---------
Co-authored-by: Orca Worker <orca-worker@localhost>
|
||
|
|
cfbf3610d5 |
fix(linux): keep Wayland clipboard text current (#27772)
Publish Linux Wayland text copies with an independent clipboard owner, then clear Chromium's stale source only after publication succeeds. Use data control where available and GTK's clipboard bridge on GNOME. Keep macOS, Windows and X11 on their existing Electron writers. Temporary workaround for https://github.com/electron/electron/issues/54645, with removal checks documented in the native README. Verified full build, macOS arm64 packaging, Linux x64/arm64 library floors, clipboard/platform tests, real Wayland copy/paste and CI packaging. Fixes #26917 Fixes #23229 |
||
|
|
81c3d188a4 |
build(macos): parallelize native helpers with complete cancellation (#19651)
* build(macos): run native module builds concurrently
* fix(build): terminate sibling native builds when one fails
Address coderabbit review: concurrent builds kept writing native
artifacts after a sibling reported failure. Track spawned children,
kill remaining siblings on first nonzero exit, and forward SIGINT/
SIGTERM to all children.
* fix(build): process-group teardown and prefixed output for parallel native builds
Address second coderabbit round:
- Detached process groups + negative-pid kill so SIGTERM reaches swift/
swiftc descendants, not just the direct pnpm child (they could keep
writing artifacts after fail-fast)
- Signal handlers preserve the received signal (SIGINT no longer becomes
SIGTERM for children) and are removed before re-raising, so the parent
actually dies instead of looping through terminateAll
- runPnpmScript settles only on close, never on error alone, so
Promise.all cannot exit while children are still running
- Per-module output prefixes ([computer]/[keyboard-layout]/[notification-
status]) match what the PR description always claimed; interleaved
swiftc errors are now attributable
- Windows path untouched (early return before any of this runs)
execa/p-limit were considered and rejected: no new runtime deps for a
build script, and detached process groups give strictly stronger cleanup
than execa's direct-child kill.
* fix(build): memoized handler removal and external-vs-sibling signal split
Second-round coderabbit findings on
|
||
|
|
df8467247d |
fix(ci): stop hourly/adhoc mac builds from executing native pnpm via node (#17331)
pnpm 12's npm_execpath is a Mach-O/PE binary. build-native-for-platform.mjs still launched it with `node $npm_execpath`, which throws SyntaxError on the binary header and fails every signed macOS dev-channel build. |
||
|
|
9f3a912c1e |
fix(terminal): type Option-composed ASCII instead of reporting it as a chord (#14743)
* fix(terminal): preserve Option-composed ASCII input * fix(terminal): preserve Option keyboard protocol semantics * fix(terminal): complete Option keyboard event encoding * fix(terminal): harden Option input encoding * fix(terminal): close keyboard protocol fallback gaps * test(terminal): prove Option-composed ASCII reaches the pty end to end The Option-compose fix had unit coverage only. This drives a live Electron pane whose kitty flags are armed by the application's own CSI > 1 u and asserts the bytes at the pty boundary: composed `@` and Shift-layer `\` arrive as text, configured Option-as-Alt still reports the layout-resolved chord, and a non-ASCII glyph still reaches the app as its alt hotkey. Restoring the pre-fix policy fails exactly the two composed-text scenarios. Also records the ASCII rule's rationale where the rule lives, not only in a test comment. * refactor(terminal): drop the unread Option layers from the layout snapshot The native helper computed an Option and Option+Shift character for every key, shipped both over IPC, validated them in the parser and cached them in the renderer — but no production caller ever asked for them. Only the base and Shift layers are read, and Shift is the one the web layout map cannot supply, which is why the helper exists at all. Removing them halves the helper's UCKeyTranslate work per key and drops the option parameter that six signatures were threading through for nobody. |
||
|
|
ee82d66a35 |
fix(cli): preserve multiline arguments on Windows (#8374)
* fix(cli): preserve multiline Windows arguments * test(cli): run Windows launcher regression in CI * fix(cli): support Windows Framework C# compiler |
||
|
|
25ea2bbfd1 |
onboarding: seamless macOS notification permission step with live state detection (#7684)
* feat(onboarding): state-aware macOS notification permission step The Set up notifications step showed a one-size-fits-all 'Open Mac Settings' button that simultaneously fired the macOS permission prompt and opened System Settings — two competing system UIs, with System Settings unnecessary for the common fresh-install case. Electron exposes no API to read macOS notification authorization, but scheduling outcomes do reveal it: a silent probe notification's 'show' event means permission is granted, 'failed' means delivery is blocked. A new notifications:probeDelivery IPC runs that probe (cached via passive delivery evidence and a persisted confirmation flag), and the onboarding card now renders the real state: - fresh install: the probe itself pops the native Allow dialog the moment the step opens; the card flips to 'Notifications are enabled' automatically when the user clicks Allow (silent 2.5s re-probes) - blocked: amber card with an Open System Settings deep-link, which also self-heals once the user flips the toggle - granted: green confirmation card The test-notification button now feeds the same card instead of the ambiguous 'if no banner appeared…' toast during onboarding. Co-authored-by: Orca <help@stably.ai> * fix: don't log expected probe rejections while polling for permission Co-authored-by: Orca <help@stably.ai> * fix: amber warning styling + single stable dev bundle id for notifications - Blocked card now uses the app's shipped amber idiom (tinted surface with amber title/body) instead of white-on-amber-wash, which read muddy in dark mode; macOS permission card split into its own module to stay under the max-lines budget. - Dev instances previously minted a unique macOS bundle id per branch x Electron version, registering a new Notification Settings entry every time ('Orca: <branch>' rows piling up forever) and pointing the settings deep-link at ids System Settings can't resolve. All dev instances now share com.stablyai.orca.dev: one Notification Center entry, one permission grant covering every dev build. Co-authored-by: Orca <help@stably.ai> * fix: tighten macOS permission card copy Body copy was one long sentence; now a single short instruction with 'Updates automatically.' as a separate dimmer line. Also repairs locale catalog parity for keys introduced by commits rebased into this branch. Co-authored-by: Orca <help@stably.ai> * fix: drop 'Updates automatically.' line; ad-hoc sign dev app copies The extra line read as confusing filler — the cards now carry one short instruction each. Dev Electron copies had broken code signatures (the Info.plist identity edits invalidate the ad-hoc seal), which macOS punishes by refusing Notification Center registration outright: every dev notification failed with UNErrorDomain error 1, the app never appeared in System Settings > Notifications, and the settings deep-link had nothing to land on. The dev runner now ad-hoc re-signs the copied bundle after the plist edits (bundleLayoutVersion bumped so stale unsigned copies are recreated). Verified end-to-end: runner-built copy passes codesign --verify --deep, probe delivery returns delivered, the onboarding card flips green in dev, and the deep link opens the dev app's own notifications pane. Co-authored-by: Orca <help@stably.ai> * fix: drop confusing copy line; session-only permission evidence Removes the 'Updates automatically.' line from both permission cards. Also drops the persisted notificationDeliveryConfirmed flag: OS-level permission changes between sessions, and a stale positive rendered a false green card. Delivery evidence is now session-scoped only. Documented detection ceiling (verified empirically on macOS 26): while the permission dialog is unanswered — and when notifications are toggled off in System Settings after being authorized — macOS accepts requests and silently swallows them, with no public API (Notification Center delivered-history and legacy ncprefs both included) able to distinguish that from real delivery. 'failed' remains definitive for unsigned builds and dialog-level denials. Co-authored-by: Orca <help@stably.ai> * feat: real macOS notification permission readout via native helper Electron has no API for UNUserNotificationCenter authorization, and every observable fallback lies: scheduling succeeds (and getHistory lists the notification) even while macOS silently swallows display because the permission dialog is unanswered or notifications were toggled off in System Settings. The onboarding card therefore showed 'enabled' after the user disabled notifications. Adds native/notification-status-macos: a tiny Swift binary that prints the app's real authorization status. It runs from inside the app bundle (NSBundle resolves the bundle by walking up from the executable) and embeds the app's CFBundleIdentifier in a __TEXT,__info_plist section so every codesign --force pass — electron-builder's signing or the dev runner's ad-hoc deep sign — derives the identifier macOS keys notification records to. Spawning it from the app returns authorized / denied / not-determined exactly matching System Settings. notifications:probeDelivery now prefers this readout (authoritative, silent), firing at most one dialog-trigger probe per session while the decision is pending, and falls back to the previous delivery-probe heuristics when the helper is unavailable. The card polls the readout silently in every state, so toggling Allow notifications in System Settings flips the card within a poll — both directions, verified live. Test notifications also consult the readout so 'delivered' is no longer claimed for swallowed notifications. Packaged builds ship the helper via extraResources and sign it in afterPack like the computer-use helper; dev copies compile it on demand (swiftc, non-fatal when missing) with the shared dev bundle id. Co-authored-by: Orca <help@stably.ai> * feat: in-app fallback for swallowed notifications + permission card in Settings - Dispatch now consults the authorization readout before creating a native notification: when macOS would silently swallow it (denied or prompt unanswered) it returns reason 'blocked-by-system' instead of piling invisible notifications into Notification Center. The terminal notification path surfaces that as a once-per-session in-app toast with an Open System Settings action. Mobile fan-out is unaffected. - Settings > Notifications now shows the same live permission card as onboarding (moved to components/notifications/), polling the readout so System Settings changes reflect within seconds, and the test button updates it inline. - Test sends that are blocked at the OS level now show the settings-pointing failure toast instead of a generic error. Co-authored-by: Orca <help@stably.ai> * fix: hide macOS permission card while Orca notifications are disabled A green 'Notifications are enabled' card next to a disabled Enable Notifications toggle read as a contradiction — the card now renders (and the readout polls) only while Orca's own notifications setting is on. Also single-flights the authorization helper so simultaneous agent completions share one readout process. Co-authored-by: Orca <help@stably.ai> --------- Co-authored-by: Orca <help@stably.ai> |
||
|
|
b8ad7e6bf7 | fix: harden packaging installers (#3878) |