Skip to content

Troubleshooting


Fix sign-in, model, connection, computer, task, and terminal problems, and file a report that gets acted on.

Start from the surface that failed and keep the exact error text. Most problems match one of the cases below.

#Sign-in does not complete

Make sure the browser can reach atoi.app and allows cookies for it. In the terminal, restart device authorization:

bash
atoi account status --json
atoi account login

If an old terminal identity is stale, sign out and back in:

bash
atoi account logout
atoi account login

#A model is unavailable

Open Settings → Models and look at the provider. A saved key shows only that the key is stored, not that every request succeeds. Try another enabled model. If it still fails, keep the provider's error message; it usually names the cause (balance, region, retired model).

A failed request stays on the message with a Resume action. Fix the cause, then resume instead of sending again. If Atoi answered with a different model than the one you picked, the message says which model ran.

See Models and keys and Providers.

#A connection cannot read or act

Open Settings → Plugins (that tab holds your Connections), then open the Connection. Check its scope and the last error. Reconnect only if the grant is missing or revoked; a connected badge does not mean access to every repository, board, or document. See Connections.

#A computer is offline

Open Settings → Computers and read the status. A computer that was connected earlier can be asleep or disconnected now. Reconnect it before assigning work. See Computers.

#A task is waiting or failed

Open the task from its thread or from the panel's Tasks tab. Look for an ask, an approval, a provider error, a failed check, or a disconnected computer. Resolve that one thing and continue the same task. Do not start a duplicate to clear the state.

#The terminal cannot connect

bash
atoi status --json
atoi doctor --json
atoi account status --json

Read the three results separately. They tell you whether the binary runs, the backend answers, and the account is authorized. When a flag looks different from an older example, atoi <command> --help is the truth.

#Write a report that gets fixed

Include the surface, the route or command, the exact error, what you expected, what state you were in, and whether it happens again after a fresh sign-in.

Never paste keys, session tokens, or unredacted credentials into a report or a thread.

Was this useful?