AI review · 2026-10-22

Security Review of Herdr, Orca, T3 Code and Clawdline

Is it safe to install Herdr, Orca, T3 Code or Clawdline? Compare independent Claude Code and Codex security reviews, with code-reading findings and full responses.

ClawdlineHerdrT3 CodeOrca

At a glance · Security-code reading requested

Protections, risks and open questions

These are condition B reviews, after security-code reading was requested. Each point keeps the original conditions and concerns. Open it for detail.

Latest Clawdline round: v2.1.3. The other three projects retain their pinned revisions and were not rerun.

  • ProtectionsWhat the reviewer found the code actually protects.
  • Risks & required trustExposure, weaknesses and what you must trust. Not a claim of an exploitable bug unless stated.
  • UnverifiedWhat the reviewer said it could not confirm. Neither safe nor unsafe; open for the reason.

Clawdline

v2.1.3fcc905914 ↗

Claude Code

Overall verdict (paraphrased)No malicious or deceptive behavior reported in the sampled source; standard cryptography and access controls were identified. The reviewer still sees substantial risk from terminal authority, hosted code and publisher trust.

Protections5
  • Signed installationThe installer verifies an Ed25519-signed manifest, then archive size and SHA-256 before unpacking.Details

    The reviewer read summarized source: no sudo, isolated Python, private installation permissions. The downloaded setup binary was not reviewed.

  • Encryption and replay checksThe reviewer traced AES-256-GCM, Ed25519 verification and Replay.Claim before decryption.Details

    This is a source-reading observation, not a runtime or attack test of every receive path.

  • Cryptographic pairingPairing uses X25519, HKDF-SHA256 and authenticated encryption; the invitation secret travels in the fragment.Details

    The reviewer describes the cryptographic design, not the Swift native bridge or private service enforcement.

  • Key-file permissionsThe file store uses owner-only permissions, atomic writes and symlink defenses.

  • Local HTTP controlsThe reviewer identified default loopback binding, Host checks and cross-site request checks.

Risks & required trust6
  • Remote authorityAn operating paired endpoint can type into terminals and expose sensitive sessions.Details

    Pairing links and clawdline open URLs carry authority and must be treated as credentials.

  • Hosted application trustA compromised hosted viewer could change the code that uses keys and decrypts content.Details

    This is an endpoint trust concern, not a reproduced compromise or proof that relay encryption is broken.

  • Publisher and build pipelineA valid signature still requires trusting the publisher and release pipeline.Details

    The reviewer flags Actions pinned to version tags and non-reproducible builds. These concerns were not exploit-tested.

  • Secrets at restMachine keys are base64 files, not encrypted hardware-backed secrets.

  • Metadata and outbound trafficCloud sees routing metadata; direct negotiation reveals IP addresses, and Cloud-off still permits update checks.

  • Additional source observationsThe response raises signature-only metadata binding, timestamp freshness, forwarded Secure-cookie behavior and recovery-key exposure.Details

    These are the reviewer’s observations from summarized pages, not independently reproduced vulnerabilities. Read the original wording and limits.

Unverified5

  • Release artifactsNo downloaded binary, signature, notarization or binary-to-source match was verified.

  • Private Cloud serviceProduction relay/API behavior, logging, retention and configuration remain unknown.

  • Browser and Swift pathsBrowser-side crypto and key storage, and the Swift code, were not reviewed.Why

    This rerun cannot establish that the separately published native-2.1.1 concerns are resolved.

  • Other mechanismsSetup, automatic updates, push and constant-time auth comparisons were not inspected.

  • Reading qualityClaude explicitly read web-fetch summaries rather than complete files.Why

    Its claim about stale design documents remains its observation; no additional validation was added to this summary.

What this summary covers, and the reviewer’s advice

What the reviewer actually readSummarized web reads of installer, Go crypto/pairing/replay, file keys and HTTP controls; no browser crypto, Swift bridge, setup or release-binary verification.

Reviewer’s adviceBegin local-only, pair trusted devices, prefer read-only and verify the exact release artifact. The pinned README still selected v2.1.2 when reviewed; later main updated the example to v2.1.3.

Each item above restates one of the response’s main conclusions in shorter form, adding no judgment the original does not make. File links, code locations and exact wording are in the full response.

Read this code review in full

Codex

Overall verdict (paraphrased)Meaningful risk remains because the tool can read sensitive developer data and control terminals. The sampled Go/browser code implements credible encryption, but the reviewer cannot certify v2.1.3 binaries or production Cloud as safe.

Protections5
  • Go and browser encryptionAES-256-GCM and Ed25519 are implemented on both endpoints, with signature verification before decryption.Details

    The report notes that sender binding depends on the pinned-key lookup. It found credible mechanisms, not full protocol verification.

  • Pairing designA random invitation secret, AES-GCM, X25519 and HKDF-derived keys protect the handover.

  • Network defaultsCloud and remote-command permission default to off; HTTPS/WSS endpoints are configured.Details

    Direct connections default to enabled when Cloud is used. The reviewer did not fully audit WebRTC.

  • Installation controlsThe installer includes a pinned Ed25519 key and release-verification machinery.Details

    That reduces substitution risk but does not independently verify the actual downloaded v2.1.3 files.

  • HTTP authorizationThe sampled source includes authentication, same-origin checks, capabilities and pairing rate limits.

Risks & required trust5

  • Endpoint authorityAn operating browser can expose secrets or cause commands under the user’s account.

  • Same-origin code trustNon-extractable CryptoKeys do not prevent malicious same-origin JavaScript from using keys or reading plaintext.Details

    This is the reviewer’s security inference; no XSS or hosted compromise was established.

  • Local key storageBase64 key files use private permissions but are not encryption at rest.

  • Metadata and updatesRouting metadata stays visible, and Cloud-off does not necessarily eliminate outbound traffic.Details

    The outbound inventory covers an earlier revision, so the reviewer did not treat it as a complete egress audit of this commit.

  • Revocation limitsRevocation cannot erase plaintext or keys already copied by a device.Details

    Production guarantees for future content were not verified; rotation code exists and its acceptance record remains qualified.

Unverified5

  • Release binariesActual signatures, notarization, manifests and binary/source correspondence were not verified.

  • Private/deployed CloudPrivate backend, deployed frontend, retention and production configuration were unavailable.

  • Service-side one-time claimsThe cryptographic pairing code does not prove that the private service enforces one-time claims.

  • Unreviewed pathsWebRTC, dependencies and all source paths were not comprehensively audited; no native Swift bridge review was performed.Why

    This is not a reassessment of the separately retained native-2.1.1 report.

  • Public-reader failuresDirectory/API listings were partly inaccessible, although pinned raw files were readable.

What this summary covers, and the reviewer’s advice

What the reviewer actually readPinned raw Go/browser crypto, pairing, settings/relay, file keys, installer, HTTP/auth and rotation/data-flow documentation; partial listing failures and no execution.

Reviewer’s adviceStart local-only without production secrets, enable Cloud only when needed, prefer read-only and verify the exact release. This review gives no unconditional installation approval.

Each item above restates one of the response’s main conclusions in shorter form, adding no judgment the original does not make. File links, code locations and exact wording are in the full response.

Read this code review in full

Herdr

a2008661c ↗

Claude Code

Overall verdict (paraphrased)No sign of malicious behavior, telemetry or hidden uploads. The real risks are ordinary supply-chain ones, plus the fact that Herdr deliberately runs and controls your coding agents and SSH sessions.

Protections6
  • TelemetryNo analytics or telemetry code or config was found.Details

    “Product announcements” only read text from the update manifest and store it locally.

  • Local IPCThe local API is only a Unix socket (mode 0600, owner only) or a Windows named pipe; there is no TCP listener.

  • Transport encryptionNo home-made crypto: HTTPS comes from curl, remote encryption from your system OpenSSH.

  • SSH host verificationSSH uses StrictHostKeyChecking=yes and BatchMode=yes, stores no passwords or keys, and shows no agent or port forwarding.Details

    SSH control sockets are restricted: /tmp/hssh-<uid>, mode 0700, with ownership checks.

  • Installation scopeThe installer writes only to ~/.local/bin, uses no sudo, does not edit shell rc files and does not run Herdr.

  • Manual updatesherdr update is manual only and never auto-installs.

Risks & required trust8
  • Download signaturesDownloads have checksums but no signatures. install.sh and herdr update take the SHA-256 from the same herdr.dev manifest as the binary, so someone who compromised herdr.dev could swap both.Details

    No GPG or minisign check, and install.sh does not pin curl to HTTPS (--proto =https).

  • Preview checksumsPreview-channel downloads may skip the checksum entirely if the manifest leaves it out.Preview channel

  • Release provenancePrebuilt binaries on herdr.dev, GitHub Releases or Homebrew cannot be tied to this source.Details

    Building it yourself (cargo build --release) closes that gap.

  • Remote installationHerdr installs its own binary on remote hosts under $HOME; when platforms match, it pipes your local binary over SSH with no checksum step the reviewer could see.Using remote hosts

  • SSH agent forwardingIts SSH config pulls in your own ~/.ssh/config, so any ForwardAgent yes there still applies.Using remote hosts

  • Plugin executionPlugin build commands run with your full user privileges and no sandbox. Installs are not pinned to a commit unless you pass --ref.Installing pluginsDetails

    A confirmation prompt lists the commands first, but --yes skips it.

  • Local API accessThe local socket does not authenticate connections, so any process running as you can drive your agent panes.Details

    The reviewer calls this normal for a tmux-style tool: protection comes from file permissions, which do not defend against malware already running as you.

  • Update-check trafficAt startup Herdr checks herdr.dev/latest.json; the server sees your IP and curl’s User-Agent.DefaultDetails

    The request adds no version, OS or ID. Homebrew installs query formulae.brew.sh instead.

Unverified6
  • Verification switchesExactly what version_check and manifest_check turn off.Why

    Both are on by default; the reviewer could not confirm what each controls.

  • IPC permissionsWindows named-pipe security and the Unix socket’s parent-directory permissions.Why

    platform/windows.rs was not reviewed.

  • Download TLS optionsThe full curl wrapper flags.Why

    Part of update.rs was cut off when fetched.

  • Windows installerHow install.ps1 uses the checksum on Windows.Why

    Not read in this review.

  • SSH agent accessHow the server uses the SSH_AUTH_SOCK path Herdr hands it.Why

    The server-side code that uses it was not visible to the reviewer.

  • Server loggingAnything on the herdr.dev server side, such as logging.Why

    Server-side behavior is outside the repository.

What this summary covers, and the reviewer’s advice

What the reviewer actually readChecksum/update, SSH transport, local API and plugin code; some large files truncated.

Reviewer’s adviceReasonable to install if you trust the herdr.dev maintainers about as much as any project you curl | sh. Safest: build from a reviewed commit, or compare a release binary’s checksum against the GitHub release yourself. Set version_check/manifest_check to false to stop startup requests, pin plugins with --ref, avoid --yes on plugins you have not read, and check that your SSH config does not set ForwardAgent yes for hosts you reach through Herdr.

Each item above restates one of the response’s main conclusions in shorter form, adding no judgment the original does not make. File links, code locations and exact wording are in the full response.

Read this code review in full

Codex

Overall verdict (paraphrased)Yes, there are meaningful security risks, though no evidence of intentional data theft in the inspected code paths. Treat Herdr as a trusted terminal controller with access to sensitive session content, not as an isolated utility.

Protections4

  • Download integrityThe Unix installer verifies the download’s SHA-256 and installs to ~/.local/bin without root.

  • SSH transportRemote terminal traffic runs inside the system ssh; saved and non-interactive connections use StrictHostKeyChecking=yes.

  • Local IPC permissionsThe local API is protected by the OS: Unix socket mode 0600; on Windows, a user-specific named-pipe security descriptor and, by default, an integrity restriction for elevated servers.

  • Background HTTPS requestsBackground fetches use HTTPS with no TLS-verification bypass and attach no terminal content in the examined functions.Details

    Background version checks only announce updates and wait for an explicit install.

Risks & required trust6
  • Publisher trustInstallation trusts herdr.dev: the checksum comes from the same manifest that picks the binary, with no independent publisher signature.Details

    An attacker controlling that manifest could replace both. The documented curl … | sh runs the live website script, which is not pinned to the reviewed commit.

  • Saved session dataSaved session data is written to disk as unencrypted JSON: working directories, launch and resume arguments, agent session references.Details

    Optional history keeps ANSI terminal content, so secrets shown on screen or passed in saved arguments can persist in readable files. The writer does not set owner-only permissions; protection depends on directory permissions, OS defaults and umask.

  • SSH configurationOrdinary interactive SSH connections depend more on your SSH configuration and normal SSH behavior.

  • Local API accessThe local API has no login or token; any process running as your account is inside the trust boundary.Details

    Do not expose or forward this socket to untrusted users.

  • Background catalog requestsBackground requests fetch update manifests and a detection catalog from herdr.dev/agent-detection/index.toml; the receiving infrastructure sees connection metadata.

  • Plugin executionPlugins are executable code: the plugin launcher runs external commands without a sandbox.Installing plugins

Unverified4
  • Effective SSH securityThe actual SSH cipher, key exchange, private-key protection and effective host configuration.Why

    These depend on the installed SSH implementation and your machine, not on this repository.

  • Feature and plugin uploadsThat every feature or plugin is free of uploads or telemetry.Why

    Only the examined functions were checked.

  • Release provenanceThat distributed binaries and the live installer match this source.Why

    No installation was performed, and the session had no shell or filesystem tool.

  • Retention and dependenciesServer-side retention policies, and the security of all dependencies and plugins.Why

    Outside what a static source review could reach.

What this summary covers, and the reviewer’s advice

What the reviewer actually readInstaller, persistence writer/snapshot, SSH attach, Unix/Windows API controls, update and plugin paths.

Reviewer’s adviceReasonable to evaluate under an unprivileged account with non-sensitive projects, but the reviewer would not approve it for confidential production work on this review alone. Use an inspected, pinned installation path; protect saved state; avoid unnecessary history retention; treat plugins as executable code.

Each item above restates one of the response’s main conclusions in shorter form, adding no judgment the original does not make. File links, code locations and exact wording are in the full response.

Read this code review in full

T3 Code

d13fc8467 ↗

Claude Code

Overall verdict (paraphrased)Nothing malicious or carelessly insecure in the code read, and the auth design is careful. The real risk is that it runs coding agents on your machine and can expose control of them to other devices; how risky it is depends mostly on configuration.

Protections7
  • Default listenerThe server listens on 127.0.0.1 unless you set a host.DefaultDetails

    Some third-party doc mirrors say it binds all interfaces by default; the code says otherwise.

  • Required authenticationThere is no mode that turns auth off, even on localhost.Details

    Local browser use needs a one-time token; the desktop app uses its own bootstrap credential.

  • Session tokensSession tokens are signed with HMAC-SHA256 using a 32-byte random key and checked in constant time; every request checks revocation.Details

    Sessions last 30 days; WebSocket tickets last 5 minutes.

  • Secret-file permissionsServer secret files use mode 0600 in a 0700 directory.

  • CORS and credentialsPackaged builds’ wildcard CORS is acceptable because it sends no credentials and the API needs a bearer token or DPoP.

  • Download integrityThe install script checks a SHA-256 checksum and uses no sudo or shell-profile edits.

  • Relay token accessPer the docs, the T3 Connect relay cannot get your session tokens.

Risks & required trust12

  • Pairing permissionsPairing links get every permission, including terminal commands and filesystem:read (any file your user can read). A pairing URL or stolen session is effectively a shell as you.Default, unless you pass --scope

  • Optional DPoP bindingDPoP key binding is optional per token; a token issued without it works as a plain bearer token if stolen.

  • Readable token claimsTokens are signed, not encrypted: anyone holding one can read its claims, but cannot change them.

  • Local secret storageLocal secrets are unencrypted .bin files and the OS keychain is not used, so any process running as you can read them.

  • Cookie Secure flagThe cookie has no Secure flag.Served over a reachable non-HTTPS addressDetails

    Harmless on localhost; a small weakness otherwise.

  • LAN exposure--host 0.0.0.0 on an untrusted network exposes the server; auth still applies, but you rely on it entirely.OptionalDetails

    The reviewer suggests Tailscale or SSH instead.

  • Cloudflare visibilityNeither the repo nor the docs say T3 Connect traffic is end-to-end encrypted; assume Cloudflare can see it.T3 Connect (optional)Details

    Cloudflare Tunnel generally decrypts TLS at the edge; the reviewer did not verify that in this repo.

  • Relay signing keyThe T3 docs admit that a leaked relay signing key would be a problem.T3 Connect (optional)

  • Default telemetryTelemetry appears to be on by default: events go to ingest.t3.codes and on to PostHog, with hashed account IDs for T3 Connect, OpenAI and Claude.DefaultDetails

    The docs say prompts, responses, file contents and tokens are excluded. T3CODE_TELEMETRY_ENABLED=false turns it off; the docs note the browser web app does not read these variables.

  • Relay tracingRelay traces are sent to Axiom.T3 Connect (optional)

  • Download signaturesThe install script has no signature check, and the checksum comes from the same release as the binary.Details

    It catches corrupted downloads, not a compromised release.

  • Agent permissionsThe agents themselves run with whatever permission mode you pick, usually the biggest real-world risk.

Unverified5
  • Provider credential storageWhere provider and source-control secrets are stored.Why

    They go to a store whose code was not shown; probably the same unencrypted 0600 file store, but not confirmed.

  • WebSocket origin checksThe WebSocket upgrade handler and any Origin check.Why

    ws.ts was truncated, though authentication clearly happens before the RPC layer.

  • DPoP validationShared DPoP checks: allowed algorithms and time window.Why

    They live in @t3tools/shared/dpop, which was not read.

  • Relay and client hardeningThe relay’s server-side code, the mobile apps and Electron hardening.Why

    Not reviewed.

  • Release provenanceThat release binaries match this source.Why

    Not verified.

What this summary covers, and the reviewer’s advice

What the reviewer actually readServer bind, auth/session/secret store, cookie/CORS and installer; WebSocket and DPoP checks incomplete.

Reviewer’s adviceReasonable to install for local use on a machine you trust. Keep the default loopback binding, pass --scope when pairing and revoke unused devices (t3 auth), prefer Tailscale or SSH over T3 Connect for sensitive code, set T3CODE_TELEMETRY_ENABLED=false if you do not want telemetry, and read install.sh before piping it to sh.

Each item above restates one of the response’s main conclusions in shorter form, adding no judgment the original does not make. File links, code locations and exact wording are in the full response.

Read this code review in full

Codex

Overall verdict (paraphrased)Yes, there are meaningful security and privacy risks. Treat T3 Code as a privileged agent and remote-access tool: the code has real authentication protections, but it does not justify calling the tool risk-free or its cloud connection end-to-end encrypted.

Protections5

  • RPC authorizationThe WebSocket server authenticates connections and enforces RPC permission scopes: filesystem, terminal, provider management and agent operations.

  • Session-token verificationSession tokens are HMAC-SHA256 signed with a random 32-byte key; verification checks expiration and revocation.

  • DPoP proofsDPoP adds P-256/ES256 proofs tied to the request and token, with replay detection.Details

    These help prevent forgery and credential reuse.

  • Download integrityThe runtime downloader checks SHA-256 against the release’s checksum file.

  • Telemetry opt-outThe server supports T3CODE_TELEMETRY_ENABLED=false.

Risks & required trust9
  • Remote controlA compromised authorized client can have substantial control: terminal access is a shell as your user, and agent-operation access can launch a full-access agent.Details

    The repository itself documents this authority boundary. Treat a standard paired device as highly trusted.

  • Plain HTTP on LANDirect LAN connections over plain HTTP are supported and give no transport confidentiality for credentials or traffic.Direct LAN route

  • Cloudflare visibilityT3 Connect forwards requests through Cloudflare to a loopback HTTP origin, and the reviewed RPC path adds no payload encryption; assume Cloudflare can access application traffic.T3 Connect

  • Relay signing authorityT3 Connect trusts its relay’s signing authority: a valid relay proof can request a short-lived, client-key-bound bootstrap credential with standard client scopes.T3 ConnectDetails

    A compromised relay signing authority remains consequential.

  • Signing versus encryptionSignatures do not encrypt: HMAC and DPoP do not conceal prompts, files or terminal output.

  • Local secret storageLocal secrets are written as unencrypted .bin files, protected only by file permissions (0700/0600).Details

    Permissions help against other OS users, not malware running as you or readable backups.

  • Local databaseThe local database is ordinary SQLite with no encryption key.

  • Default analyticsAnalytics is on by default and sends HTTPS batches to ingest.t3.codes, which retains a copy and forwards to PostHog. Hashed IDs from Codex, Claude and connected accounts make it potentially correlatable.DefaultDetails

    Payloads include installation IDs, platform/version information and event properties. The reviewer did not establish that every event excludes sensitive content.

  • Latest-version installationInstalling “latest” (live installer or npx t3@latest) does not install the reviewed source, and the checksum comes from the same release location.Details

    This detects mismatches but does not protect against a compromised release publisher.

Unverified4
  • End-to-end encryptionApplication-level end-to-end encryption that excludes Cloudflare.Why

    The reviewer could not verify it; the inspected RPC path showed no extra payload-encryption layer.

  • Production transport and logsProduction TLS versions, tunnel cryptographic settings and logging.Why

    Not available from the repository.

  • Provider credential storageEvery provider’s credential store.Why

    Only the inspected storage paths were checked.

  • Release supply chainLive installers, release signatures, the dependency supply chain and binary reproducibility.Why

    Not verified; nothing was installed and no exploits were tested.

What this summary covers, and the reviewer’s advice

What the reviewer actually readWebSocket/RPC, tunnel configuration, HMAC/DPoP, secret store, telemetry and runtime downloader.

Reviewer’s adviceFirst evaluate it under a separate OS account or disposable environment, keep remote access disabled, disable telemetry if unwanted and use supervised agent permissions. Avoid plain HTTP across a network. For sensitive repositories, review the exact release and remote-access deployment before granting access.

Each item above restates one of the response’s main conclusions in shorter form, adding no judgment the original does not make. File links, code locations and exact wording are in the full response.

Read this code review in full

Orca

7a06b6579 ↗

Claude Code

Overall verdict (paraphrased)No sign that Orca is malicious or quietly sends your data somewhere; relay encryption, telemetry and secret storage are reasonably built. The real risk is what the tool is for: broad control of your machine for AI agents and, optionally, a paired phone.

Protections6
  • Pairing identity verificationThe v2 phone–desktop protocol keeps the relay from reading traffic: the desktop public key is in the pairing QR code and checked during the handshake, so the relay cannot swap in its own key.Mobile pairing (optional)Details

    The relay sees only ciphertext plus metadata such as timing, sizes and IDs.

  • Encrypted message protocolEach direction gets its own HKDF-SHA256 session key; messages are authenticated with nacl.secretbox, and sequence numbers reject replayed or reordered messages.

  • Device-token transportThe phone’s device token is sent inside the encrypted channel, after the handshake.

  • Default listenerThe WebSocket listener stays on loopback until you generate a LAN/QR pairing offer.Default

  • Telemetry consentTelemetry to PostHog is consent-gated: nothing is sent until you choose. GeoIP is off, and source builds send nothing.Details

    It sends app version, OS, a persistent install ID and a session ID, with schema-checked event fields. DO_NOT_TRACK=1, ORCA_TELEMETRY_DISABLED=1 or any CI environment disables it.

  • Settings-secret storageSettings secrets are encrypted with Electron safeStorage (OS keychain) and are not written in plaintext if encryption is unavailable.

Risks & required trust7
  • Pairing QR-code lifetimeThe pairing QR code is a long-lived credential: no expiry or one-time-use check was found, so anyone who photographs it can pair.Mobile pairing (optional)Details

    It contains the device token, desktop public key, connection address and relay details.

  • Paired-phone permissionsA paired phone has wide powers (terminal.send, terminal.create, agent.launch, files.read, git.push, github.mergePR, ssh.connect), effectively shell access as you.Mobile pairing (optional)

  • Legacy v1 protocolThe old v1 protocol is still accepted: requireV2 defaults to false, and v1 has no handshake binding and no visible replay protection.Default in codeDetails

    Whether production builds turn requireV2 on is unconfirmed (see below). This is a protocol weakness, not a demonstrated downgrade attack.

  • Local encryption keyThe E2EE private key is stored as plain base64 JSON, protected only by file permissions (0600 or Windows ACLs).

  • LAN WebSocket transportThe LAN WebSocket is plain ws:// without TLS and relies on the encryption layer above it.Details

    On Windows, a firewall rule is created only through an explicit “repair” action with a UAC prompt; it applies to Private networks but does not restrict remote addresses.

  • Device-token comparisonThe device token is compared with ===, not in constant time.Details

    The reviewer rates this minor: it happens inside the encrypted channel.

  • Agent and desktop controlAgents run with your full user permissions, and Orca offers “Computer Use” for desktop apps.Details

    Treat agent output and any repository you point it at as untrusted.

Unverified6
  • Production protocol versionWhether production builds turn requireV2 on.Why

    The code default is false; the shipped setting could not be checked.

  • Relay authentication and logsRelay authentication and backend behavior, including logging.Why

    The API and auth services are in a private repository (stablyai/orca-cloud).

  • Release and updater verificationWhether released builds match this source, and how the auto-updater checks signatures.Why

    Covers DMG, EXE, AppImage, Homebrew and AUR builds; updater.ts was not read in depth.

  • Mobile appThe mobile app.Why

    mobile/ was not reviewed.

  • Linux safeStorage backendOn Linux, whether a weak safeStorage backend such as basic_text is rejected.Why

    Not traced.

  • Electron hardeningElectron hardening: sandbox, contextIsolation and CSP, plus Design Mode and the embedded browser.Why

    Not reviewed. Files were read through a fetch tool that summarizes pages with a smaller model, so the reviewer calls this a targeted review, not an audit.

What this summary covers, and the reviewer’s advice

What the reviewer actually readAbout 35 security-related desktop/shared files; mobile app and private backend not reviewed.

Reviewer’s adviceIf you do not need the phone app, do not pair; the listener then stays on loopback. If you pair, treat the QR code like a password, revoke unused devices, and prefer “This computer only” or relay mode over LAN exposure on untrusted networks. Set DO_NOT_TRACK=1 or decline the telemetry prompt for zero analytics. Install from the official release or Homebrew cask and check the code signature. Run agents only on repositories you trust.

Each item above restates one of the response’s main conclusions in shorter form, adding no judgment the original does not make. File links, code locations and exact wording are in the full response.

Read this code review in full

Codex

Overall verdict (paraphrased)Yes, there are meaningful security and privacy risks. Treat Orca as a trusted remote-development app with access to your user account; the reviewer would not install it directly on a machine holding sensitive credentials without isolation.

Protections5
  • Remote RPC encryptionRemote RPC encryption is implemented, not just claimed: TweetNaCl authenticated encryption; v2 derives separate directional keys with HKDF-SHA256 bound to the handshake transcript and fresh nonces, and checks session IDs and sequential counters.Details

    These protect against tampering and replay.

  • Relay device authenticationRelay connections require v2, authenticate the device inside the encrypted channel, and check its identity against the relay connection.Relay route

  • Desktop-control grantDesktop control requires an additional grant.

  • OS-backed secret storageA separate secret-storage adapter uses Electron’s OS-backed safeStorage.

  • Telemetry consentUsage events from official builds are consent-gated and sent over HTTPS.

Risks & required trust10
  • Workspace and host permissionsWorkspace access is defined as running commands as your user, and paired clients also get account, settings, skills and host-administration permissions.Details

    A compromised authorized client can therefore have serious consequences even when encryption works correctly.

  • Legacy direct protocolDirect connections still support legacy framing without v2’s session and counter replay checks.Direct routeDetails

    The reviewer calls this a protocol limitation, not a demonstrated authentication bypass.

  • Push-notification contentPush notification titles, bodies, worktree IDs and agent state go to the push gateway in readable JSON, not end-to-end encrypted.Push notifications onDetails

    Titles are clipped to 80 characters and bodies to 180; clipping is not redaction.

  • Local encryption keyThe desktop E2EE private key is stored unencrypted as base64 JSON.Details

    Unix 0600 and Windows ACLs limit access but do not encrypt. Malware running as you or an accessible backup could read the key.

  • Key-file permission failuresWhen saving that key, Orca does not check whether restricting the file’s permissions actually succeeded.

  • Pairing listener exposureCreating a pairing offer widens the listener to all interfaces, even when you choose local-only pairing.Mobile pairing (optional)Details

    The LAN transport is plain HTTP/WebSocket with application-layer encryption above it. Authentication remains necessary, but other machines can reach the listener.

  • Telemetry identifiersIf you agree to telemetry, it carries a persistent install ID, a session ID and OS/app information.Official builds, after consent

  • Opt-out eventOpting out in the app deliberately sends one final opt-out event.

  • Uploaded diagnosticsDiagnostic bundles you upload can be read by the service that receives them.When you upload diagnostics

  • Dependency install scriptsInstalling from source runs a postinstall build and native rebuild, so installing dependencies is itself code execution.Installing from source

Unverified3
  • Production Cloud servicesThe cloud API and authentication services, their production retention and access controls, and whether deployed services match this source.Why

    They are explicitly in a private repository.

  • Credential storage pathsEvery credential persistence path.Why

    The safeStorage adapter does not establish that every credential or local record is encrypted, and its own reporting acknowledges unavailable or weak keyring configurations.

  • Release supply chainReleased-binary equivalence, complete dependency safety and the full updater verification chain.Why

    Static code review only; the installer was not run.

What this summary covers, and the reviewer’s advice

What the reviewer actually readRPC scopes, crypto/key schedule/framing, socket wiring, push, key storage, telemetry and diagnostics.

Reviewer’s adviceEvaluate it in a VM or separate OS account with disposable repositories and narrowly scoped credentials. Keep mobile pairing and push notifications disabled at first. For confidential work, the readable notification path and private cloud components need particular scrutiny. Nothing inspected proves malicious intent, but the code does not justify calling the tool unconditionally safe.

Each item above restates one of the response’s main conclusions in shorter form, adding no judgment the original does not make. File links, code locations and exact wording are in the full response.

Read this code review in full

The same question, two reading conditions

What changes when the reviewer reads the security code?

A

General question

Is there a security risk in installing this tool?

The question and pinned repository URL; Clawdline’s latest round also includes its published v2.1.3 release URL. Reviewers choose what to read.

B

Security-code reading requested

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.

The same question and commit, with an explicit request to read security code and explain what cannot be verified.

The new Clawdline round supplied only public source/release URLs and the question, with repository context disabled; visible tool records contain network reads only. Both initial Codex jobs lacked network tools and were excluded as technical failures, then retried once each. This does not mean all built-in instructions were removed; original status footers remain. Both conditions pin the same commit. A reading request does not establish complete source coverage.

A · General question

What reviewers say without a reading requirement

On a phone, scroll the table sideways to compare both reviewers.

Project / sourceClaude CodeCodex
Clawdline
fcc905914 ↗

No malicious sign reported; recognizes signed installation while flagging remote authority, hosted-code trust and release-pipeline weaknesses. Actual release assets and local authentication were not verified.

Reading scope: Installer, release workflow/metadata, pinned-key source and public security/contributor documents through web reads; no setup or binary review.

Read the full response

Finds substantive signed-install and HTTP safeguards, but meaningful risk from sensitive-data access, remote control and hosted-client trust. No specific exploitable vulnerability or clean bill of health established.

Reading scope: Pinned README, installer, HTTP gate/auth and data-boundary documents; selected raw files readable despite tree/API and security-site failures.

Read the full response
Herdr
a2008661c ↗

No malicious behavior seen; ordinary installer/publisher trust and powerful local control. Flags unsigned checksums and optional plugins/SSH.

Reading scope: Installer, update code, local socket and agent integrations; plugins and remote code not audited.

Read the full response

Meaningful risk from terminal control, native plugins and persisted state. Installer checksums share the download publisher’s trust boundary.

Reading scope: Committed installer, API server, plugin runner, persistence and configuration defaults.

Read the full response
T3 Code
d13fc8467 ↗

Reasonable to install with tighter settings; flags Full access defaults, broad pairing authority, telemetry and Cloud trust.

Reading scope: README/package and permission, remote-access, environment-auth and telemetry documentation.

Read the full response

Meaningful risk from Full access defaults and remote authority. Recognizes scoped authentication; no authentication bypass established.

Reading scope: Permission/auth/remote documentation, RPC authorization and installation instructions.

Read the full response
Orca
7a06b6579 ↗

No malware signs seen; emphasizes agent, credential and phone authority. Relay encryption was not verified in this reading.

Reading scope: Repository structure, package.json and documentation; not a line-by-line source audit.

Read the full response

Finds permission-bypass launch flags enabled by default. Recommends Manual permissions and isolation before sensitive use.

Reading scope: Agent launch defaults/permissions, startup integrations, browser security and telemetry consent.

Read the full response
Expand the previous Clawdline v2.1.2 round

The previous pinned revision, four full responses, reading scopes and limitations remain available. Only Clawdline was refreshed for v2.1.3; the other projects were not rerun. Neither round is a security certificate.

v2.1.2 · 239adc8ad ↗

Additional reading · Targeted review

The 2.1.1 native pairing bridge

A separate Chinese-prompt review of the released 2.1.1 bridge. Both reviewers flagged recipient binding under a compromised hosted page and user confirmation. These are static findings without attack reproduction, presented separately from the 16 English-prompt comparison responses. The new v2.1.3 responses did not read the Swift bridge and cannot establish that these concerns are resolved.

Claude Code ↗Codex ↗

Reading the results

“There is a risk” needs context.

Capabilities and vulnerabilities

Reading conversations and executing commands are capabilities of these tools. Unauthorized exploitation requires specific evidence. Concerns in each report still deserve investigation.

Transmission needs a closer look

“Sends data” does not say whether the payload is plaintext, ciphertext, or metadata, or who holds the keys. Condition B asks reviewers to inspect these mechanisms before answering.

An observation, not a ranking

These 16 responses are not a statistical experiment or a comprehensive audit. They establish neither agent bias nor that any project is free of security issues. Summaries are editorial; full responses let you judge for yourself.

Download prompts, source revisions and original-output hashes ↗

This page is published by Clawdline, which is also one of the projects reviewed. Project icons identify their respective projects and imply no endorsement.

Explore Clawdline’s encryption and data boundaries ↗