Troubleshooting

The errors you are most likely to see, and what each one actually means.

LOCAL_EXECUTOR_OFFLINE

No CLI is connected for the machine that serves this project. Run exeora connect there 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. Update with npm i -g @exeora/cli. 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.

NO_ACTIVE_PROJECT

Only on the account URL, and only when nothing has said which project a call is for. Call list_projects to see what the connection reaches, then set_active_project to choose one. A connection given exactly one project never sees this: there is nothing to choose between.

The message differs in the case worth telling apart. "The project you were working in is no longer available" means access to the chosen project was revoked while the connection was using it. It is refused rather than moved somewhere else on your behalf, even when one project is left, because the agent still believes it is where it chose. Choose again and it continues.

"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

tools/list is answered for the project the connection is currently working in, so a client that listed its tools while pointed at one machine can be holding a list the next project's machine does not serve. The call fails rather than doing something unexpected. Ask the client to reconnect, or update the older machine's CLI.

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.