Skip to content
AppsTerminal

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.

bash
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.

bash
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.

Capture pending: TUI Home with a Thread selected and the composer readycapture pendingTUI Home with a Threadselected and the composerready120×36atoi tui / Home
TUI Home with a Thread selected and the composer ready

#3. Ask in a Thread

Send from the TUI composer. Use an explicit CLI command when you already know the Thread.

bash
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.

bash
atoi inbox list --json
atoi inbox approve <item-id> --request <request-id> --confirm
Capture pending: TUI Inbox with one Ask and its approval detailscapture pendingTUI Inbox with one Ask and itsapproval details120×36atoi tui / Inbox
TUI Inbox with one Ask and its approval details

#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.

bash
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.

bash
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.

Capture pending: TUI Tasks section with Result, Changes, Checks, and Proofcapture pendingTUI Tasks section with Result,Changes, Checks, and Proof120×36atoi tui / Tasks
TUI Tasks section with Result, Changes, Checks, and Proof

#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.

bash
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.

bash
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?