axio-tui
Textual TUI application for axio.
A full-featured terminal chat interface with session management, a plugin system for transports and tools, and a built-in SQLite context store. Pick your LLM backend, load your tools, and start chatting - all from the terminal.
Features
- Plugin system - transports, tools, and guards discovered automatically via entry points
- Session management - persistent SQLite-backed conversations; fork, switch, and resume sessions
- Streaming UI - text and tool calls rendered incrementally as they arrive
- Multi-transport - switch between Anthropic, OpenAI, Nebius, Codex, or any registered backend at runtime
- Sub-agent support - the
subagenttool lets the agent spin up nested agent sessions - Vision -
visiontool for image analysis (with compatible models) - Serveable -
textual-servesupport for browser-based access
Installation
Minimal (core TUI only, bring your own transport):
pip install axio-tui
With everything:
pip install "axio-tui[all]"
Pick what you need:
pip install "axio-tui[openai,local,mcp]"
| Extra | Installs |
|---|---|
anthropic |
axio-transport-anthropic |
openai |
axio-transport-openai |
codex |
axio-transport-codex |
local |
axio-tools-local |
history |
axio-context-sqlite |
mcp |
axio-tools-mcp |
guards |
axio-tui-guards |
all |
Everything above |
Quick start
pip install "axio-tui[openai,local]"
axio
On first launch, press Ctrl+P to configure a transport and choose a model. Sessions and UI settings are stored in ~/.local/share/axio-tui/axio.db.
Workspace instructions, skills and MCP
TUI and REPL compose providers from axio-tools-local and axio-tools-mcp. Both load global and project AGENTS.md,
local Agent Skills, MCP tools, MCP skills, and ordinary MCP resources. New scoped instructions
reach the model before the affected tool batch runs. Subagents keep separate instruction
snapshots and retain the same tools and resource schemas.
Start axio from the working directory. The nearest Git root defines the project boundary;
without Git, the working directory is the root. Use --project-root PATH to override it
and repeat --additional-root PATH for independent roots.
MCP configuration loads in this order, replacing each server entry as a whole:
$XDG_CONFIG_HOME/axio/mcp.json(default~/.config/axio/mcp.json).<root>/.mcp.json.<root>/.axio/mcp.local.json.- Explicit
--mcp-config PATHfiles.
Enabled servers connect automatically. A failed connection does not disable other servers.
Manual servers in Manage MCP Servers remain available alongside file configuration;
use distinct server names to avoid tool-name collisions. Manual servers also expose skills
and resources. Resource URIs, including skill://, are passed unchanged to their server.
Local skills come from the same home directories as REPL. Add explicit locations with
--skills-dir PATH. Skill bodies load only when the agent reads them or you open them in the skills window. Use --instructions-file PATH
for explicit instructions. --isolated disables automatic instructions, home skills,
file MCP configuration, and saved manual MCP servers; explicit paths still load.
Use these commands in the input field or their equivalents in Ctrl+P:
| Command | Result |
|---|---|
/skills |
Open the local and MCP skills browser |
/mcp |
Open the detailed MCP server browser |
/permissions |
Inspect and revoke chat or project permission rules |
/instructions or /config |
Show instruction sources and redacted MCP configuration |
/config reload |
Reload instructions, skills, and automatic MCP connections |
The skills window shows full descriptions and source paths or URIs. Filter by name,
description, or source, then press Enter or Open skill to read the instructions.
Copies with identical full SKILL.md content share one entry, with their paths or
URIs separated by commas. Filtering matches every path. Different content stays
separate, even when names and descriptions match. Local files use content hashes;
MCP catalogs supply hashes that are verified when the skill is opened.
Use Tab to move between the list and details, Ctrl+F to filter, and Esc to close.
Automatic and manual MCP connections have separate labels. The layout stacks vertically
in narrow terminals. Read failures appear inside the window and can be retried.
The MCP window includes automatic and saved connections. Expand a server to browse its tools, resources, URI templates, and skills. Select an item to see its full description, input schema, or resource metadata. Server details include configuration sources, connection state, protocol, capabilities, and discovery errors. Connection secrets remain masked. Filter by name or metadata, use Tab to scroll the details, and press Esc to close. Refresh reads the current connection state and cached catalogs; it does not reconnect servers or execute tools.
Open Manage in /mcp to add, edit, rename, enable, disable, or delete file-based
servers. Choose User (~) for ~/.config/axio/mcp.json (or the XDG path),
Project (.) for <root>/.mcp.json, or private for <root>/.axio/mcp.local.json.
Additional roots and explicit configuration files appear with their full paths.
The editor preserves other entries and rejects edits if the file changed while open.
Deleting an override can expose a lower-priority entry. Changes reconnect MCP when
you close the manager. Isolated mode still loads only explicit files.
For HTTP authorization, select Authorization header and enter the complete value
(for example, Bearer ...), or select OAuth (browser sign-in). Save the entry,
select it in the manager, and click Authorize. OAuth uses server discovery and
dynamic client registration by default. Pre-registered public clients can specify
an issuer, client ID, scopes, and callback port. The callback is
http://127.0.0.1:<port>/callback. A zero port selects a free port on first sign-in;
later sign-ins reuse the registered port. Open the displayed URL manually if the
browser does not start. Closing the authorization window cancels pending sign-in.
OAuth credentials stay in $XDG_CONFIG_HOME/axio/mcp.auth, separate from MCP JSON
and the settings database. Connections refresh saved tokens without opening a browser.
Sign out removes local tokens and keeps the client registration; it does not revoke
access at the authorization server. Configurations with the same endpoint, issuer,
client ID, and fixed callback port share this local authorization. Header credentials are saved in the
selected JSON file with mode 0600; use environment references or a private file
when the project configuration is committed. The Additional options field accepts
headersFrom, envFrom, environment values, timeout, and other supported JSON options.
Use Reconnect all, /mcp reconnect (alias /mcp reload), or Reconnect MCP in
the command palette to reconnect both automatic and saved servers. The window closes
and progress appears in the chat. Tools and catalogs are updated after reconnection.
Initialization has one deadline per server, covering the handshake and all catalogs.
The default is 30 seconds. Set timeout in the server's JSON configuration, or edit
Initialization timeout (seconds) in Manage MCP Servers for a saved server. Progress
and errors show the server and its limit. Other servers still connect after a failure.
Stopping a stdio process can take up to five additional seconds before it is killed.
/skills reload and /instructions reload reload the workspace.
Stop an active run before reconnecting MCP or changing accounts. Shell and MCP tools can
access paths outside the workspace; instruction scopes do not provide filesystem isolation.
Tool permissions
Read-only file operations inside the project root run without a prompt. Reading
outside the root, writing files, and operations with unknown effects require a
matching rule or confirmation. Explicit denials take priority over automatic reads
and allow rules. The root is the discovered project root or --project-root, not
necessarily the shell's current directory. Additional workspace roots do not receive
automatic permission.
The dialog shows the tool, arguments, resolved resources, and reason for asking. Choose This call only, Until this chat ends, or Save for this project, then allow or deny. File rules cover the displayed operations and exact paths; selecting parent directories explicitly includes their descendants. Reading never grants permission to write. Shell, Python, MCP, and other opaque calls use exact tool/argument approvals, not command prefixes or model-generated categories. Changing an MCP server configuration invalidates its previous exact-call approvals.
Open Ctrl+P → Permissions or /permissions to inspect and revoke rules.
Project rules persist in the TUI configuration database under the canonical project
root. Chat rules expire when you start, restore, or fork another chat; compaction
keeps them. Exact-call rules store a fingerprint instead of raw arguments.
Revocation affects subsequent calls, not tools that are already running.
Every agent tool, including MCP and subagent tools, passes through the policy after
its original guards. Concurrent prompts form a queue and recheck rules before asking.
Cancellation closes the pending dialog without granting permission. Rules also work
without axio-tui-guards. The old PathGuard configuration no longer controls TUI
permissions. An optional LLM reviewer supplies advice, never an automatic grant.
Tool providers declare their effects with Tool(access=...) or a handler decorator:
from pathlib import Path
from axio.tool import Tool
from axio.tool_access import file_access, tool_access
@tool_access(file_access("read", "filename"))
async def read_text(filename: str) -> str:
return Path(filename).read_text()
tool = Tool(name="read_text", handler=read_text)
A custom descriptor returns every Access(operation, path) the handler can perform.
Paths are relative to the process working directory, as for the local file tools.
Recursive tools must declare symlink targets they follow. An absent declaration means
unknown effects; an explicit empty tuple declares no external effects. The host trusts
installed provider code, not claims in model arguments or MCP tool descriptions.
These are pre-execution checks, not an OS sandbox. Paths are resolved again after confirmation, but another process can still change the filesystem during execution. Running shell or Python code in the project directory does not restrict its effects to that directory.
ChatGPT accounts
Install axio-tui[openai], open Ctrl+P → Configure ChatGPT, and select
Continue with ChatGPT. The screen supports new accounts, returning sign-in,
registration selection, plan-permission status, sign-out, and a ChatGPT Usage link.
Over SSH, copy the authorization URL and paste the complete browser redirect URL into
the screen. Closing the screen cancels an unfinished sign-in.
Credentials use the same protected $XDG_CONFIG_HOME/axio/chatgpt.auth file as
axio-chatgpt and REPL. SQLite stores the selected registration reference, never its
tokens. Model choices reload for the selected account. Model copies share its token
session, and existing copies retain their original account. Account settings remain
accessible when signed out or model discovery fails. API-key and Codex settings remain separate.
Architecture
axio-tui
├── App (Textual)
│ ├── ChatScreen - message list, input, streaming
│ ├── SessionScreen - session list and management
│ └── SettingsScreen - per-plugin configuration
├── SQLiteContextStore - persistent conversation history
├── TransportRegistry - discovers axio.transport entry points
└── Plugin system
├── ToolsPlugin - wraps axio.tools.settings providers
└── PermissionGuard - wraps axio.guards providers
Built-in tools
These tools are always available regardless of installed plugins:
| Tool | Description |
|---|---|
confirm |
Submit an LLM review verdict; does not grant permission |
status_line |
Update the TUI status bar from within the agent |
subagent |
Spawn a nested agent with its own tools and context |
vision |
Analyse an image file (requires a vision-capable model) |
Plugin entry points
axio-tui discovers plugins automatically when installed packages declare:
# Transport backend
[project.entry-points."axio.transport"]
openai = "axio_transport_openai:OpenAITransport"
# Tool group with settings screen
[project.entry-points."axio.tools.settings"]
docker = "axio_tools_docker.plugin:DockerPlugin"
# Simple tools (no settings)
[project.entry-points."axio.tools"]
shell = "axio_tools_local.shell:Shell"
# Permission guards
[project.entry-points."axio.guards"]
llm = "axio_tui_guards.guards:LLMGuard"
Serve over HTTP
axio --serve --web-listen localhost:8086
# Open http://localhost:8086 in your browser
Part of the axio ecosystem
axio · axio-transport-anthropic · axio-tui-guards · axio-tools-local · axio-tools-mcp · axio-tools-docker
License
MIT
Both applications discover axio.tools.providers entry points. They pass initialized
providers to Agent, which handles instruction activation and associated tools.
TUI settings and permission guards also apply to tools added by an instruction.
The TUI's own tools use a provider enabled by application="tui"; installing the
TUI does not expose its UI callbacks in the REPL.
Optional integrations
The base installation starts without tools, transports, or persistent history.
Install axio-tui[local] for local files and instructions, axio-tui[mcp] for
MCP, and axio-tui[history] for SQLite conversations. These extras are independent.
Transport extras and guards remain optional; all includes history.
Without a context backend, the interface labels history as temporary. New chats, forks, and compaction work in memory; previous chats cannot be restored after restart. TUI configuration still uses its own SQLite database.
Tools and instruction providers use axio.tools.providers; plain tools use
axio.tools. Refreshable providers implement refresh(*, config=None).
Context backends register zero-argument factories in axio.context, implementing
axio.plugins.ContextBackend. The application initializes the first available
backend and closes it at shutdown. Failed providers report a diagnostic without
preventing independent providers from starting.
Without a transport, configuration and inspection remain available. Sending a request requires configuring a transport. Unavailable saved models remain in configuration until the user explicitly selects another model.
Metadata
Release files for axio-tui 0.12.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| axio_tui-0.12.1.tar.gz | 93.5 kB | With provenance | Details for axio_tui-0.12.1.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| axio_tui-0.12.1-py3-none-any.whl | Python 3 | none | any | Details for axio_tui-0.12.1-py3-none-any.whl |
Total release size: 170.0 kB
Release files / axio_tui-0.12.1.tar.gz
| Download URL | axio_tui-0.12.1.tar.gz |
|---|---|
| Size | 93.5 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
ca9e8c507413c72f6ec3767878d20987c5aaddb2ad16f0f75b62c89fc540d473
|
|
BLAKE2b-256 checksum How to use checksums |
756512120a971da0a031ef16b5a552a9ee8160658e0646690b74140af35df0bf
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 17, 2026.
Transparency logRelease files / axio_tui-0.12.1-py3-none-any.whl
| Download URL | axio_tui-0.12.1-py3-none-any.whl |
|---|---|
| Size | 76.5 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
c28ec74f4269d8e3432b749ec6510279bb33b3d217bc1c1d25a2270983156459
|
|
BLAKE2b-256 checksum How to use checksums |
d740274313b4cf47d4f737f2ddc18aca69775838f303d39e664f7c93ba657558
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 17, 2026.
Transparency logSecurity for axio-tui 0.12.1
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Full provenance
Both files in this release have been uploaded with provenance metadata.
Attestation for axio_tui-0.12.1.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 17, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.