Computer use from the CLI
Turn on computer use from your terminal - make any machine a Nebula local device, choose whether agents can run commands, and manage the daemon.
nebula-ai local-device enable turns on computer use: the machine you're on becomes a local device your agents can use. It's the headless counterpart to the desktop app's setting - same result, no window required, which is what makes it the right tool for a server or a dev box you reach over SSH.
The command enables host execution and starts a persistent helper. Agents can run commands and access files on this computer; the helper continues after the CLI command exits. Run nebula-ai local-device disable to turn computer use off.
It takes the directory you ran it from as the working folder without printing a line about it. Pass --primary-folder <path> to name one explicitly and it confirms with Working folder set to <path>.
It does say how far agents can reach. Commands start in the working folder, and by default file tools can reach your home directory; shell commands aren't confined to either and can read anything your account can. To keep file tools inside the working folder, open nebula-ai in that folder, choose Computer control at the bottom of the rail and pick Limit scope to this folder only on the Computer Use screen. Allow whole system widens it again, after you confirm.
What enabling does
It performs these steps, in order.
Signs you in, if you aren't already.
Turns computer use on in host mode, with a persistent helper.
Uses the folder you ran it from as the working folder. Pass --primary-folder <path> to point somewhere else.
Registers this machine as a device in your active workspace.
Starts the daemon that lets agents reach it.
Run it from the directory you actually want agents working in. It takes the current directory silently, so cd first.
A local device starts private to whoever registered it - nobody else in the workspace can see it or send work to it, not even the workspace owner. Only its owner can change that, by naming teammates under People with access on the device in the desktop app's Settings → Workspace → Devices (see Computer use). There's no CLI command for it, and no admin override.
Whether agents can run commands
Registering a device and letting agents execute commands on it are two separate decisions.
| host | none | |
|---|---|---|
| Agents can run commands | Yes | — |
| Files in the working folder | Yes | No |
| Set with | local-device exec-mode set host | local-device exec-mode set none |
| Best when | You want agents to use this machine | You want computer use off |
host is the CLI's equivalent of the desktop app's Allow using my computer; none is Don't allow.
nebula-ai local-device exec-mode get prints the current mode. A running daemon picks a change up on its own - you don't need to restart it.
How often computer control asks you first is separate again. In the full-screen app, Settings → Approvals & Account → Device access lists what each device allows: Enter steps a grant through Ask each session, Ask every time and Always allow, and d removes it.
Check from the TUI
To check whether agents can run commands on the computer you're typing on, choose Computer control at the bottom of the rail - the screen it opens is titled Computer Use - or run nebula-ai local-device status from your shell. The room header doesn't show it.
It describes this machine, not where a given reply ran. A channel's work runs on the devices that channel uses, and this page covers turning this machine on and choosing its working folder.
Managing the daemon
nebula-ai local-device status reports whether computer use is on, which workspace the device belongs to, and whether the daemon is running.
start, stop, and restart do what they say. nebula-ai local-device logs shows what the daemon has been doing.
nebula-ai local-device disable turns computer use off for the workspace you're in and retires this device, so the machine forgets it and the daemon stops - the next enable registers it afresh. If the desktop app on this computer still has computer use on, that stays on. nebula-ai uninstall goes further: it removes this device and, unless you pass --keep-data, the CLI's configuration and logs.
The daemon runs only while computer use is on. It does not reinstall itself as a system service and does not survive a reboot - start it again after one, or re-run enable.
When status and reality disagree
status asks the server where this machine is actually attached and prints the
answer on a Server: line, rather than guessing from local state. That matters
because a machine serves one workspace at a time - so enabling it from a second
workspace moves it, it doesn't add it.
When the two don't line up, status says so and names the fix:
| What it tells you | What to do |
|---|---|
| The device is attached to another workspace | Re-run enable from the workspace you want |
| The server has no such device | Re-register with enable |
| Known, but not serving any workspace | Attach it with enable |
| The credentials were rejected | Sign in again with nebula-ai login |
The recovery is the same command each time - nebula-ai local-device enable, run
from the workspace you want this machine to serve. Only enabling from another
workspace moves it; background reconnects leave your choice alone.
Seeing more than one workspace under Enabled in? That's expected, and it isn't a contradiction - the machine can be enabled in several, but only the one on the Server: line receives commands.
The working folder
The working folder is where agents read and write by default. On the CLI it tracks the directory you launched from, but only among folders you've already approved - the CLI keeps a list of the ones you said yes to, and a separate list of the ones you said never to. Land in a folder that's on neither list and it asks. What differs per surface is whether Nebula takes the folder or asks for it.
Open nebula-ai in a folder it hasn't seen and it asks first:
Work in this folder? - with three answers: Yes, work in this folder,
Not now (it asks again next launch), or Never for this folder. Only
never is remembered as a refusal; not now lasts the session. Until you
say yes, the agent works in the cloud sandbox rather than on your machine.
nebula-ai chat asks the same question at the prompt, as
Work in ~/code/api? [Y/n/never] - Enter accepts, and only the literal word
never opts into permanence. It skips the question entirely under --json
or when there's no terminal attached, and skipping isn't recorded as a
refusal.
nebula-ai local-device enable doesn't ask - it takes the folder you ran it
from, unless --primary-folder <path> says otherwise.
An ACP editor session uses the directory the editor opened it in, without asking.
Saying yes can do more than point the agent at a folder. If computer use was off, answering Yes, work in this folder turns it on, scoped to that folder and lasting while Nebula is open - the option says so underneath. When computer use is already on, the same option reads The agent starts here. Computer use stays as it is.
So you change it by going somewhere else and starting again - and saying yes
when it asks. Inside the app, Computer control at the bottom of the rail opens
Computer Use, which shows whether this machine is open to agents at all. local-device status names the folder.
This is where the CLI and the desktop app differ. The desktop app lets you pick a folder outright; the CLI takes its cue from where you start it. They write the same setting, so starting the CLI somewhere else can repoint the folder you chose in the app. It asks you first: unless you'd already approved that folder, in which case it repoints silently.
Agents can also move themselves within a thread, and that's separate from this machine-level default. An agent can change the folder it's working in, switch the conversation to one of your other devices entirely, or do both at once - and whichever it picks holds for the rest of that thread. Switching machines starts it in that device's home folder rather than carrying the old path across, since a path from one machine rarely means anything on another.
Checking for Claude Code
If your agents hand work to Claude Code on this machine, nebula-ai local-device claude-code get tells you which claude a turn would find, and its version.
The part in brackets says how it was found: path when it's on your PATH, or login-shell when only your login shell's PATH has it. If it can't find claude at all, it says so and suggests installing Claude Code.
Related
Put Nebula to work
Get Nebula on your computer or phone, then create your first channel and set its goal.
App agents: let an agent use an app on your computer
Create an app agent in Nebula desktop to drive one app on your computer, like Figma, Notes or Excel. Connect the app, hand it work and disconnect it.
Capsule, Quick Chat and shortcuts
Keep Nebula a keystroke away on desktop with the floating Capsule, Quick Chat, QuickLive calls, the tray menu, and global and in-app keyboard shortcuts.