Terminal
Use `atoi` to sign in, ask in a Thread, answer an Ask, run a Task, read its Receipt, share from the TUI, and connect your Computer.
Use the terminal for explicit commands, structured JSON, keyboard navigation, or a connected Computer. Choose the atoi CLI or open the TUI with atoi tui.
#1. Sign in
Authorize the CLI in your browser, then confirm the current operator identity.
atoi account login
atoi account status --json
Use atoi account logout when you want to revoke that terminal identity. This is separate from pairing the machine as a Computer.
#2. Arrive in the TUI
Open the keyboard-first client.
atoi tui
Start in Home for the active conversation. Move among Projects, Threads, Tasks, Inbox, Search, Channels, Automations, Settings, Skills, and Doctor with the section shortcuts shown in the sidebar.
#3. Ask in a Thread
Send from the TUI composer. Use an explicit CLI command when you already know the Thread.
atoi thread list --json
atoi thread send --thread <thread-id> --prompt "Audit this release and show the blockers"
Add --model and --reasoning when you need to override the Thread's current choices. The CLI and TUI both verify context references, model selection, and reasoning strength in the submitted message.
#4. Answer an Ask
Open Inbox in the TUI, select the exact item, and confirm its request identity before you approve or deny it. Use the CLI for the same action in a script.
atoi inbox list --json
atoi inbox approve <item-id> --request <request-id> --confirm
#5. Start and watch a Task
Choose a Project and execution place, then start the Task. Use wait until it needs you or reaches a terminal state.
atoi task start --project <project-id> --profile safe --place cloud --prompt "Run the release audit"
atoi task wait <task-id> --json
Use atoi task cancel <task-id> to stop it or atoi task continue <task-id> --prompt "Check the remaining blocker" to continue the same record.
#6. Read the Receipt
Open Tasks in the TUI or read the command output. Check Result, Changes, Checks, and Proof before you act on a change set.
atoi task get <task-id> --json
atoi task changes <task-id>
Apply or prepare a draft PR only after you inspect the immutable change-set ID and fingerprint. Both actions require explicit confirmation and return a Receipt.
#7. Share from the TUI
Open a Thread in the TUI and choose the public share action. Select the conversation or message scope, review the boundary summary, and confirm. Copy the returned link and read the redaction Receipt. Public sharing works in the TUI; the CLI has no command for it today.
#8. Connect your Computer
Pair this machine, then keep the companion online when Atoi needs its shell, files, git, browser, or screen.
atoi login
atoi connect
Use atoi companion status to check the local pairing. Use atoi connect --once when you want the Computer to claim one Task and exit.
#9. Open the implementation runtime
Run the product-owned durable runtime explicitly when you want to work directly in a repository.
atoi mono
atoi mono -p "Inspect this repository and summarize the entry points."
atoi mono --continue
The bare atoi command remains the product CLI. Tasks and Receipts remain the durable record around implementation work.
Use the CLI reference for every command and flag, and open Troubleshooting when account, Computer, or backend checks fail.
#On this surface today
In the TUI today you can use:
- The full message composer.
- Group participants, presence, feedback, reactions, and public sharing.
- Thread and Channel lifecycle.
- Preferences, provider Connections, Skills, and Plugins.
- Operator and companion state.
- Project lifecycle, Workspace binding and source truth.
- Task lifecycle, proof, inspection, apply, and draft-PR actions.
- Search, For You, Inbox decisions, and Automations.
With the CLI today you can use:
- The message composer.
- Preferences, provider Connections, Skills, and Plugins.
- Operator authorization and session state.
- Companion state.
- Project lifecycle, Workspace binding and source truth.
- Task lifecycle, proof, inspection, apply, and draft-PR actions.
- Search, Inbox decisions, and Automations.
MCP verifies only Project, Workspace, Task, proof, and change-set records. The current inventory does not claim that every feature has parity.
#Where it differs
- Compared with the web, the terminal verifies Task lifecycle, Workspace source truth, and Task apply and draft-PR actions.
- Compared with the web, the CLI uses explicit commands and JSON envelopes, while the TUI keeps keyboard navigation and a visible record hierarchy.
- Compared with the web, provider authorization, Channel authorization, Plugin installation approval, companion pairing, checkout, and the final public page still hand off to browser routes.
Was this useful?