Installing Orca IDE on Debian from the Terminal (and Why I Turned Yolo Mode Off)

I installed Orca, an open-source IDE for running AI coding agents in parallel, on Debian entirely from the terminal — then turned off its Yolo mode, built a sandbox repo, and walked the git worktree cycle by hand before letting an agent near it.

$ cat table_of_contents.txt

Lab Journal — Debian desktop, Orca 1.4.239

Why Orca

Orca is a free, open-source (MIT) desktop IDE from Stably AI built for running AI coding agents — Claude Code, Codex, OpenCode and others — side by side. Its core trick is git worktrees: every task gets its own branch and its own folder, so agents can’t trample each other or my main branch. I already run Claude Code on my desktop and laptop, so I wanted to see what an orchestration layer on top of it looks like.

This post covers the install, the onboarding choices I made, and a hands-on walkthrough of the worktree cycle — done by hand first, before letting an agent do it.

Step 1: Get it from the right source

The first thing I noticed searching for Orca: several forks of the project live on GitHub under other people’s accounts. The official sources are onorca.dev and github.com/stablyai/orca. Downloading a desktop app from a look-alike repo is a textbook supply-chain risk, so I went straight to the publisher.

Instead of clicking through the releases page, I asked the GitHub API which .deb files the latest official release ships:

curl -s https://api.github.com/repos/stablyai/orca/releases/latest | grep browser_download_url | grep '\.deb'

That returned two packages for v1.4.239 — amd64 and arm64. My desktop is amd64.

Step 2: Download and install

cd ~/Downloads
wget https://github.com/stablyai/orca/releases/download/v1.4.239/orca-ide_1.4.239_amd64.deb
sudo apt install ./orca-ide_1.4.239_amd64.deb

The ./ matters: it tells apt to install the local file and resolve dependencies, rather than searching repositories.

The package lands in /opt/Orca. Listing it shows the usual Electron/Chromium furniture — chrome-sandbox, .pak resource files, libffmpeg.so, Vulkan and GLES libraries — plus the main binary, /opt/Orca/orca-ide.

Step 3: The CLI surprise

Typing orca-ide didn’t open a window. It printed a long help screen. The orca-ide on my PATH is the Orca CLI, not the app. To launch the desktop window:

orca-ide open

That returned the app’s PID and runtime status. graph_not_ready looked alarming but just meant no project had been added yet.

The security angle: that help screen is worth reading. The CLI is built so agents can drive the machine — clicking and typing into desktop apps, evaluating JavaScript in a built-in browser, setting HTTP credentials, reading localStorage, sending text into live terminals, and running Orca as a pairable server with optional desktop control. It’s the same browser-automation idea from Black Hat Python, packaged for AI agents. Powerful, and worth treating with respect.

Step 4: Onboarding — and Yolo mode

Onboarding detected 13 agents on my system and pre-selected Claude, which is what I wanted.

Then I noticed Yolo mode was switched on by default. Its own description says agents run commands and edit files without asking, and some bypass their sandbox. On a desktop that holds my Docker containers, pentest VMs, SSH setup and Tailscale network, that’s one prompt injection away from a bad night. I turned it off. Agents now have to ask before acting — human in the loop, least privilege, the same principle as IAM in the AWS DVA-C02 material.

Step 5: A sandbox repo, not my home folder

Orca needs a git repo to create worktrees. Pointing it at my home directory would expose .ssh, .bashrc and everything else to whatever agent I launch, so I made a throwaway repo:

mkdir -p ~/projects/orca-sandbox
cd ~/projects/orca-sandbox
git init
git branch -m main
git config --global init.defaultBranch main
echo "# Orca sandbox" > README.md
git add README.md
git commit -m "Initial commit"

Worktrees need at least one commit to branch from, hence the README. Then I registered it with Orca from the terminal:

orca-ide repo add --path ~/projects/orca-sandbox

One line in the output deserves attention: hookSettings set to run setup scripts by default and start the agent immediately. My setup script is empty, so it’s harmless here — but for a repo cloned from someone else, a setup script could run commands automatically. Check it before creating worktrees on untrusted code.

Step 6: The worktree cycle, by hand

I was near my weekly Claude usage limit, so instead of launching an agent I created a worktree named test-1 with no agent selected (clearing the Claude field in the dialog) and walked through the cycle myself.

Orca put the worktree at ~/orca/workspaces/orca-sandbox/test-1, outside the original repo. git worktree list showed one repository, two folders, two branches, both at the same commit:

/home/lvydvy/projects/orca-sandbox                48e69a9 [main]
/home/lvydvy/orca/workspaces/orca-sandbox/test-1  48e69a9 [test-1]

I created hello.txt in the worktree and confirmed it did not appear in ~/projects/orca-sandbox — isolation proven. After committing it, the branches visibly diverged (main at 48e69a9, test-1 at 5a5f266).

Accepting the work was a fast-forward merge:

cd ~/projects/orca-sandbox
git merge test-1

Then cleanup through Orca’s CLI, so its sidebar stays in sync:

orca-ide worktree rm --worktree name:test-1

That removed the folder and the test-1 branch. git branch showed only main.

Lessons learned

  • Verify the publisher. Forks of popular tools are everywhere; go to the official org.
  • Read the CLI help. It told me exactly what this tool can do to my machine.
  • Check defaults. Yolo mode on by default is a choice the vendor made for convenience, not safety.
  • Scope the blast radius. A sandbox repo, not a home directory.
  • Learn the plumbing first. Doing the worktree cycle by hand means I’ll understand what an agent is doing when it does it for me.