A3S Code TUI

a3s code is the interactive terminal application for A3S Code. It is shipped by the a3s CLI, embeds the a3s-code-core runtime, and renders the runtime event stream with a3s-tui.

Use the TUI when you want a ready coding-agent terminal. Use the SDK packages when you are building your own harness, IDE extension, server worker, workflow runner, or product UI.

Surface Map

Install

Install the CLI, then run a3s code from the workspace you want the agent to inspect:

brew install A3S-Lab/tap/a3s

# or from crates.io
cargo install a3s

# or from the CLI repository
cargo install --git https://github.com/A3S-Lab/Cli

a3s code
a3s code resume <session-id>
a3s code update

The top-level a3s update command is also accepted by the CLI and routes to the same updater.

Configuration

The TUI discovers config in this order:

1. A3S_CONFIG_FILE
2. .a3s/config.acl walking upward from the current directory
3. ~/.a3s/config.acl

The TUI uses .a3s/config.acl for project-local configuration. SDK examples often use agent.acl because embedders pass the config path explicitly with Agent.create("agent.acl"). Both are ACL files; the important difference is who discovers the file.

Keep real keys, private provider URLs, tenant identifiers, and user-specific paths out of commits. Public templates should resolve credentials through environment variables:

default_model = "provider/model-id"

providers "provider" {
  apiKey = env("PROVIDER_API_KEY")
  baseUrl = env("PROVIDER_BASE_URL")

  models "model-id" {
    tool_call = true
    limit = {
      context = 128000
      output = 4096
    }
  }
}

Filesystem-First Workflow

The TUI is workspace-oriented. When launched in a repository, it can load the same filesystem-first conventions used by SDK sessions:

These files make behavior reviewable, but they do not bypass runtime gates. Permission policy, confirmation prompts, workspace checks, tool visibility, response contracts, and verification still run through A3S Code.

Runtime Event Stream

The TUI treats AgentSession::stream() as the source of truth. Runtime events drive transcript text, tool-call progress, planning state, approval prompts, memory views, git/file panels, verification evidence, and replayable run state.

This split matters for product builders: the TUI is one opinionated client over the runtime. SDK embedders can build different controls over the same session, tool, event, persistence, and verification APIs.

Slash Commands

Built-in slash commands include:

Some commands are accepted only while the session is idle because they mutate conversation, model, context, or process state.

Related Pages

1. Filesystem-First
2. Sessions
3. Commands
4. Tools
5. Security