Troubleshooting

Signing in over SSH

exeora login opens a browser on this machine and waits for a callback on localhost. That cannot work in an SSH session, a container, or a machine with no display. Run exeora login --code instead. The terminal prints a URL and a code; open the URL on another device, type the code shown here, and the CLI finishes signing in. Only enter a code displayed on a terminal you control.

LOCAL_EXECUTOR_OFFLINE

No CLI is connected for the machine that serves this project. Run exeora connect on that machine and leave it running.

It fails immediately rather than waiting, on purpose. Nothing is queued, because a command landing hours later when a laptop wakes up is worse than one that never ran.

The gateway closed the connection

Two reasons, and the message says which:

• The machine was revoked from the dashboard. Registering it again takes exeora connect --reset.
• The protocol version is out of range. Run exeora upgrade. It replaces the installed binary with the newest release. Adding to the protocol does not normally break an installed CLI, so this is rare; when it happens the message names both versions.

A change is refused with "not approved"

The project asks for every change to be confirmed and nobody answered within ninety seconds. Look at the terminal running exeora connect, or at the banner in the dashboard.

If that machine has no terminal, which is the case under systemd or in a detached tmux pane, the question only ever goes to the dashboard. Keep a tab open, or turn confirmation off for that project.

A command is refused as shell syntax

The project has a command list in force, and the command carries a pipe, a redirect, a substitution or a chain. Any of those makes the first word a poor description of what the command will do, so it is refused rather than matched.

Rewrite it as a plain command, or, if the project is one you would have left open anyway, turn on shell and accept that both lists become suggestions. See what a project allows.

The agent cannot see a tool

Two things hide a tool. The project's tools list may not name it, which is a setting in the dashboard. Or the connected machine may be running a CLI too old to have it, since the gateway only advertises what the executor announced: update the CLI.

A multi-project call does not name a project

Only on the account URL, and only when a connection reaches several projects. Call list_projects to see the valid targets, then pass a project slug or id on the tool call. A connection given exactly one project may omit it because there is nothing to choose between.

Project selection is not stored on the client. Repeat the same project value on every related call, including calls that read, write to or stop a process started earlier. This lets separate conversations use separate projects at the same time.

"This connection has not been given access to any project" means every project it had was revoked or deleted. Authorize the client again from its own settings and tick the projects it should reach; if it still appears under Clients in the dashboard you can give it projects back there instead.

The account URL offers a tool a project cannot run

With several reachable projects, tools/list cannot assume one target, so a client can see a tool that one project's machine does not serve. A call naming that project fails rather than doing something unexpected. Update the older machine's CLI if it should offer the same tools.

A project the gateway does not know

exeora status marks these, and they happen when a project was removed from the dashboard while this machine was not looking. exeora sync reconciles the two.

A process disappeared

Processes started with start_command die when the CLI disconnects, including across a reconnect. That is deliberate: a dev server nobody can reach, read or stop is not a feature. Start it again after the connection comes back.

No keychain on this machine

Most Linux servers and CI containers have no secret service. The CLI falls back to a 0600 file under $XDG_CONFIG_HOME/exeora/ and says so when it happens. Nothing else changes.

Linux says GLIBC_ is not found

The published Linux binary is linked against glibc 2.31, which is Ubuntu 20.04 LTS. A machine older than that — Ubuntu 18.04, Debian 10, CentOS 7 — will refuse to start it. Upgrade the distribution. If the machine can run the repository's required Rust toolchain and build dependencies, a native source build may work, but systems with glibc older than 2.31 are not supported.

The Windows installer says x64 is unsupported

Exeora's Windows release is an x86_64-pc-windows-msvc executable. The installer checks the native Windows architecture, not the bitness of the PowerShell process running it. A 32-bit PowerShell on 64-bit Windows reports PROCESSOR_ARCHITECTURE=x86; Windows exposes the native AMD64 value in PROCESSOR_ARCHITEW6432. The installer uses that override when it is present, so running the command from 32-bit PowerShell no longer produces a false unsupported-architecture error.

ARM64 Windows is still not accepted because Exeora does not publish an ARM64 CLI binary. The error now includes the detected architecture so that a genuine platform mismatch can be distinguished from the old process-versus-OS detection problem.