← Back to the comparison

Independent review · Full response

Orca

Orca · Codex · Security code review

2026-10-227a06b6579 ↗Public-web access only

Exact prompt

Is there a security risk in installing this tool? Read the security-related code in this repository and understand its encryption and data transmission mechanisms before answering. If a mechanism cannot be verified from the accessible code, say so.
Pinned repository link supplied with the question ↗

The text below is the agent’s complete original response, with its original language identified. The introduction is editorial, not part of the original output or an independently verified conclusion. No installation or attack testing was performed.

Editorial introduction

Confirms v2 encryption and replay controls. Separately flags readable push payloads, unencrypted key files and widened network exposure.

Reading scope: RPC scopes, crypto/key schedule/framing, socket wiring, push, key storage, telemetry and diagnostics.

Download the complete original English text · SHA-256 302fd5aadfa00b18756a5d1aca49af3381403a8f38a60c33faa2c82929f3f36c

Complete original response

Yes—there are meaningful security and privacy risks. I would treat Orca as a trusted remote-development application with access to your user account, and would not install it directly on a machine holding sensitive credentials without isolation. I found real encryption and authentication controls, but they do not protect every data path.

This assessment covers accessible source at commit 7a06b6579bbd106b0cb9bb53978f2cacc7326b9f. It is a static code review; I did not execute the installer or verify a released binary.

  1. Remote access has substantial privileges. The code explicitly defines workspace access as the ability to run commands as the host’s user. Paired runtime clients also receive account, settings, skills, and host administration permissions; desktop control requires an additional grant. A compromised authorized client can therefore have serious consequences even when encryption works correctly. Permission definitions, caller permissions

  2. The remote RPC encryption is implemented, rather than merely claimed. The shared primitives use TweetNaCl box.before and authenticated encryption. Version 2 derives separate directional keys using HKDF-SHA256, binds them to a handshake transcript and fresh nonces, and checks session identifiers and sequential counters. These are useful protections against tampering and replay. Crypto primitives, key derivation, frame verification

    Relay connections require version 2 and authenticate the device inside the encrypted channel, additionally checking its identity against the relay connection. Direct connections still support legacy framing, which lacks the explicit session/counter replay checks present in v2. This is a protocol limitation, not a demonstrated authentication bypass. Socket wiring, channel implementation

  3. Push notification contents are readable by the push gateway. Notification titles, bodies, worktree identifiers, and agent state are serialized into JSON and sent to /v1/send. They are not encrypted end to end with the phone in this path. The dispatcher clips titles to 80 characters and bodies to 180; clipping is not secret redaction. Sensitive text appearing in a notification could therefore leave your machine in readable form at the service endpoint. Notification payload construction, gateway transmission

  4. The desktop E2EE private key is not encrypted at rest. It is stored as base64 in JSON. The file helper applies Unix 0600 permissions and Windows ACL restrictions, but those protect access rather than encrypt the contents. Malware running as your user, or someone obtaining an accessible backup, could read the key. The keypair writer also does not check the helper’s boolean result indicating whether permission restriction succeeded. Key storage, file protection

    A separate secret-storage adapter uses Electron’s OS-backed safeStorage. That does not establish that every credential or local record is encrypted; its own protection reporting acknowledges unavailable or weak keyring configurations. I could not verify every credential persistence path. Secret-storage adapter

  5. Pairing expands network exposure. Ordinary desktop startup configures the WebSocket listener for loopback initially. Creating a mobile pairing offer widens it to all interfaces—even when selecting local-only pairing. The LAN transport uses plain HTTP/WebSocket with application-layer encryption above it. Authentication remains necessary, but the listener becomes reachable by other machines. Startup configuration, pairing behavior, transport

  6. There are additional outbound data paths. Official builds can send consent-gated usage events to PostHog over HTTPS, including persistent installation ID, session ID, and OS/app information. Opting out through the UI deliberately sends one opt-out event. Diagnostics have a separate upload mechanism; uploaded bundles are readable by the receiving service. Telemetry transport, diagnostic upload

What remains unverified: the cloud API/authentication services are explicitly in a private repository. I cannot verify their implementation, production retention/access controls, or whether deployed services match this source. I also did not establish released-binary equivalence, complete dependency safety, or the full updater verification chain. Source installation executes a postinstall build/native-rebuild process, so installing dependencies is itself code execution. Cloud source boundary, installation scripts

My recommendation is to evaluate it in a VM or separate OS account with disposable repositories and narrowly scoped credentials. Keep mobile pairing and push notifications disabled initially. For confidential work, the readable notification path and private cloud components require particular scrutiny. Nothing I inspected proves malicious intent, but the accessible code does not justify calling the tool unconditionally safe.

Fixed but not yet released (awaiting review): Nothing.

← Back to the comparison