Using the CLI inside a computer
Every computer carries the CLI, so the agent can use it from its own commands: start a thread in another workspace, check on an automation, archive a finished thread. Bash and code the agent runs find it on their PATH as both la and langalpha. The agent’s commands run without your shell’s aliases, so la is safe there.
The CLI runs on the machine’s own Node.js and needs version 20 or later. Daytona, E2B and Docker computers ship it. On a machine you added over SSH it is whatever the machine has installed, and adding a machine without it warns that the agent will have no CLI there. A machine without it answers la with “needs Node.js 20 or newer on this computer”.
The computer’s token
Section titled “The computer’s token”The agent does not use your sign-in. The server gives each computer a token of its own and sets LANGALPHA_TOKEN_FILE in the environment of every agent command, naming a file that holds the token and the server it belongs to. The CLI reads that file on every request, so a long command keeps working while the server replaces the token.
A computer’s token lasts about an hour and is renewed while the computer runs. Stopping or deleting the computer revokes it at once, so a copy taken off the machine stops working. Because LANGALPHA_TOKEN_FILE is set, the CLI in an agent command never falls back to a sign-in of yours that happens to be saved on the same machine, and never sends the computer’s token to another server.
What the agent can do there
Section titled “What the agent can do there”A computer’s token holds the agent:read, agent:run, workspace:write, computer:write and data:read scopes, but only for what that computer holds. In practice the agent can:
- list and read threads, workspaces and automations on its computer;
- start a thread in another workspace on the same computer, or send to one of its threads;
- create workspaces on its computer, create, edit and pause automations there, and archive threads;
- start its own computer.
What it is never allowed to do
Section titled “What it is never allowed to do”Some actions are refused to a computer’s token whatever scopes it holds, because the agent itself holds that token:
| Refused | Why |
|---|---|
| Anything in Home, or on another computer | Home runs the Chief of Staff, which reaches every computer, and each computer reaches only what it holds. |
| Deleting anything | The agent archives or pauses instead; deletes stay with you. |
| Adding or pairing a computer | A machine it added would hold a token of its own that outlives this one. |
| Stopping, archiving or removing its own computer | It would cut off the command that asked. |
| Answering an approval or a question | An agent approving its own requests would defeat them. |
| Editing or regenerating a turn | That would drop the turns after it. |
| Sending into the thread the command runs in | That would loop the conversation into itself. This covers stopping that thread’s turn and triggering an automation that runs into it. |
A refused call exits with code 3 and the server’s reason, for example “A computer’s token never reaches Home”. A computer is also limited to 10 requests a second, with short bursts up to 60, which only a loop reaches.
How its work shows up
Section titled “How its work shows up”A thread the CLI starts from inside a computer, or a message it sends, is marked as coming from the thread whose command ran it, and the app shows it as “From another thread”, linked to that thread. The server records every call a computer’s CLI makes with that thread, refused calls included.
Example
Section titled “Example”From a turn in the NVDA workspace, the agent can hand a side task to the Semis workspace on the same computer and keep going:
la threads new "Update the peer comps table with this quarter's results" -w Semis --detach --jsonla threads follow <thread_id> --json