CLI reference

Everything below connect is a piece you can run on its own.connect signs in and keeps the machine online; project add registers a directory.

connect

A few flags for the cases it cannot guess:

While connect is running, Exeora asks the operating system to keep both the machine and its display awake. The request covers relay reconnects and is released when the command exits. It does not override an explicit sleep request or closing a laptop lid. If the operating system cannot create the request, Exeora warns once and continues connecting.

login

exeora login opens a browser on this machine. On a server, a VM, or any SSH session where that cannot work, pass --code. The terminal prints a URL and a short code. Open the URL on a phone or laptop, type the code from the terminal, and approve Exeora. Do not paste a code you did not just see on a machine you control: that would sign their machine in as you. exeora connect --code does the same thing on the way to staying online.

gateway

Exeora is open source, so https://exeora.dev is a default rather than an address. exeora gateway use https://your.example.com points this machine at your own deployment and stores the choice, so every later command follows it with no flag and no variable. exeora gateway prints the active one and where it came from; exeora gateway reset goes back to the hosted one. exeora login and exeora connect take --gateway to do the same thing on the way past.

workspaces

exeora workspace create feature/name creates a native Git worktree wrapped as an Exeora workspace from the current workspace's HEAD, registers it under the current Exeora project and synchronizes its stable id with the gateway. Use --from <ref> to choose another base, or --reuse-existing-branch when the branch already exists. --project selects a project when the command is not run inside one.

attach connects an existing workspace without taking ownership of its creation. detach only disconnects it from Exeora. remove runs Git's worktree removal and refuses uncommitted changes unless --force is present; branches are kept unless --delete-branch is requested, and then Git's safe branch -d is used.

The default root follows the platform data directory. EXEORA_WORKSPACE_ROOT overrides it for one environment, while exeora config set workspace-root <path> persists it. A gateway outage leaves a safe pending record and exeora sync retries it.

One gateway is active at a time. Switching forgets the machine registration, the projects and the session belonging to the previous one, because a device id issued by one gateway's database means nothing to another. The CLI lists what it is about to forget and asks before it does. It also checks that a gateway actually answers at the address before touching anything, so a typo leaves a working setup exactly as it was.

init

Interactive by default. Pass --yes to take the flags as given and ask nothing, and --force to replace a file that already exists.

exeora init --yes --mode allow_list --allow "npm,git *" --deny "sudo,rm *"

--tools takes the same comma-separated form. See what a project allows for what the values mean.

prompt

Writes the prompt to stdout and nothing else, so it pipes. Every MCP client already receives this over the wire; the command is for the ones that never ask. Pass --account for the variant that explains choosing between projects.

exeora prompt > AGENTS.md

See the agent prompt for what it says and the other three ways to get it.

upgrade

exeora upgrade downloads the newest stable GitHub release for this operating system and CPU, verifies its published SHA-256 checksum, and safely replaces the running executable with it.

The upgrade needs write access to the executable. Installations made with the standard scripts live in a user-owned directory, so they do not normally need elevated privileges.

Machine-readable output

--json makes status, logs, device list and project list, workspace list and config get print one JSON document instead of drawing on the terminal. Errors become JSON on stderr with a non-zero exit, so a caller piping stdout into a parser gets either valid JSON or nothing.

exeora logs --json | jq '.[] | select(.status == "error")'

status carries accountMcpUrl alongside each project's own mcpUrl, on both the signed-in and signed-out shapes, so a script can find the URL that covers every project without having to build it.

On connect, which never finishes, it prints one JSON object per line as things happen, which is what a supervisor or a log collector can read as it arrives. In that mode there is nobody at the terminal, so confirmations go to the dashboard instead. The awake event reports whether system and display sleep prevention is active, with a reason when the operating system rejected the request.

Where things are stored

The refresh token goes to the OS keychain. Machines with no secret service, which is most Linux servers and CI containers, get a 0600 file under $XDG_CONFIG_HOME/exeora/ instead, and the CLI says so when it happens. Everything else is plain JSON; exeora status prints the path.

EXEORA_GATEWAY_URL points the CLI at a different gateway for one shell, without overwriting the stored value it outranks. For anything longer lived, including a self-hosted deployment you use every day, exeora gateway use is the one that sticks.

The one thing it asks for

On the third interactive run, if the GitHub CLI is installed and signed in, Exeora asks once whether to star the repository, and does it with gh if you say yes. It checks first whether you already starred it, in which case it never asks. Say no and it goes quiet for a long while, asks a second and last time, then never again.

The question needs a real terminal, so it never appears under --json, in CI, in a script, or on a machine without gh. EXEORA_NO_STAR_PROMPT=1 turns it off outright. Left unanswered for thirty seconds it takes the default, which is yes, and prints the one command that undoes it.