A fresh Orca worktree can use a shared dependency directory or receive a copied .env file, depending on the project's sharing settings. That's a consequential detail in a project whose October 14 GitHub Trending snapshot, collected by MrKeyoor, recorded 962 stars gained that day. Developers considering its parallel coding agents need to decide which parts of their environment each attempt should inherit.
Orca is an MIT-licensed workspace for command-line coding agents, available for macOS, Windows, and Linux. You bring the agents and their subscriptions. The app puts their terminals and code changes into a common interface, with separate Git worktrees for parallel attempts. Its repository showed roughly 92,000 stars when checked for this article, a measure of interest that doesn't establish how many developers use it or how much time it saves.
The recent work concerns the machinery around those agents. Desktop version 1.4.224, released October 10, moves SSH hosts toward a managed Orca server. An October 13 Android prerelease makes the paired desktop supply most mobile screens and features. Both changes make the execution host more central to what you see and control.
Separate checkouts, connected environments
Git worktrees let several checkouts belong to one repository. Each can have its own current commit and working files, while branch references and repository configuration are generally shared. Git's documentation explains those boundaries, including an extension for configuration specific to each worktree. A separate checkout is useful for comparing changes, but it doesn't create a separate repository or an operating-system security boundary.
For example, two agents can attempt the same fix on different branches without editing the same tracked file. You can inspect both results before choosing one. Shared Git references mean their branches still belong to the same repository, however. The practical reading of Git's worktree model is that checkout separation solves a file-coordination problem. Permissions for commands and access to resources outside that checkout need their own controls.
Orca adds ways to prepare the files Git leaves out. Its worktree guide documents per-repository Shared Paths, which use an APFS clone-copy on macOS where possible and otherwise a symlink. A checked-in orca.yaml can name ignored directories such as node_modules for sharing. A separate .worktreeinclude lists ignored files or directories to copy into each new checkout.
That last file supports literal paths, including .env, rather than globs or negation. Paths already shared aren't copied again. These documented rules make setup worth reviewing before starting several agents: a symlink points at shared data, while a copied configuration file belongs to the new checkout. Copying a secret-bearing file still gives the new environment that secret.
Folder trust reaches beyond the branch
Orca also prepares trust settings for the tools it launches. The 1.4.224 release notes say folder pre-trust is enabled by default, with a switch under Settings → Agents. For someone expecting each agent to stop at its usual folder-trust question, that default changes the launch experience. Review it alongside the agent's own command permissions.
An earlier fix shows why the surrounding configuration matters. In version 1.4.221, released October 5, the maintainers reported that marking a folder trusted for GitHub Copilot could leave ~/.copilot/config.json readable by other users on the machine. That file can contain login tokens. Versions 1.4.219 and 1.4.220 also applied the behavior on SSH hosts.
The same release note says Orca now makes the file readable only by its owner after writing it. A file affected by an older version is repaired the next time Orca adds a folder. That condition matters on a shared host: the stated repair happens on a subsequent configuration write. The disclosure doesn't establish that anyone accessed a token, and it shouldn't be read as evidence of a breach.
Remote execution has its own permission switch
The SSH guide says Orca creates the worktree and runs the agents on the remote host, while exposing file changes and terminal activity through the client. That keeps the location of execution distinct from the location of the interface. A command you supervise from your laptop is still running with the remote account's access.
By default, an SSH host's orca CLI can reach its own terminals and orchestration messages, including reporting to the coordinator that dispatched work. It can't control other hosts, desktop functions, accounts, or settings. The documented opt-in for broader control on that host lets its agents create worktrees, open terminals, and dispatch work. Those are separate powers from editing a checkout.
Version 1.4.224 supplies a runtime for the managed remote server, reducing dependence on the host's Node installation or build tools. Hosts without open terminals migrate on their next connection. Hosts with terminals offer a migration that restarts them, according to the release notes. The convenience therefore has an operational consequence: choosing when to move an active host is part of supervising its work.
More workers need completion records and review
Orca's experimental orchestration layer distinguishes a task from a dispatch, which is one attempt to carry out that task in a terminal. Worker completion and heartbeat messages identify both. A coordinator-owned decision can block a task until it's resolved. The structure gives a supervisor a way to tell which attempt reported completion when tasks are retried or reassigned.
The guide also distinguishes a Run, which holds a namespace and inbox, from scheduling workers. Creating one doesn't place agents automatically. Its supervised workflow starts workers explicitly and requires completion messages to report success or failure. For developers evaluating the feature, that makes a better first exercise than counting open agent tabs: dispatch one bounded task, inspect its output, and check that its reported outcome matches the work.
Code review has a more familiar interface. Annotate AI Diff lets you attach comments to lines or ranges, then send them to a selected agent as one batch. Comments remain pinned after revision, and unresolved ones can go into the next batch. That preserves the reviewer's objections while the agent edits, instead of relying on a fresh chat message to describe every location again.
Those comments still need an acceptance criterion. The documented review loop provides a place to ask for a correction and inspect the response. It doesn't demonstrate that the corrected program behaves properly. A useful trial should include a change you can verify independently, with tests or a reproducible check suited to that change.
The phone follows the host
The mobile companion documentation labels the app beta and describes it as a remote control for an existing desktop session. You can read agent activity, answer prompts, and review source-control changes. The desktop remains the source of truth, so having a phone interface doesn't move the underlying job onto the phone.
The October 13 Android prerelease tightens that relationship: most screens and features come from the paired desktop, and a desktop update reaches the phone on its next connection. The release also says undelivered messages return to the draft marked as unsent. For remote supervision, knowing whether an instruction arrived is more useful than merely seeing a responsive composer.
Orca's own analytics are another separate consideration. Its telemetry policy says packaged builds send usage events with an anonymous local identifier and platform information, excluding prompts, file contents, and agent output. You can disable transmission in Settings → Privacy or with ORCA_TELEMETRY_DISABLED=1. That policy describes Orca's product telemetry; the agents you connect have their own data handling.
Start with a release build and one controlled task
Our Orca review covers the setup reality: a September 29 source checkout installed 1,295 packages in an 8 GB sandbox, then failed its build and exceeded a 900-second test limit. Those results belong to that checkout and environment. They don't establish that today's packaged application fails, and the review recommends starting with a release build before taking on source development.
Watch the next releases for changes to host permissions and recovery after a lost connection. The current orchestration guide still labels the feature experimental. For a first trial, use one bounded task with a result you can check. Add another worker after you've inspected what the first inherited and what it changed.