console-app

Console App

The Ariadne Console is a command-line client that brings the full power of Ariadne to your terminal. It supports interactive and headless modes, has direct access to your local filesystem, and can integrate with IDEs via the Agent Control Protocol (ACP).

Installation

Linux — one command

curl -fsSL https://<your-ariadne-instance>/install.sh | sh

The script is served by your Ariadne instance with its own URL already stamped in (the Download CLI dialog in the web UI shows the exact command for your instance). It:

• installs a self-contained Console bundle into ~/.ariadne/app — no .NET installation required;
• keeps a copy of itself at ~/.ariadne/ariadne and puts that on your PATH, so afterwards you just run ariadne;
• checks the published bundle's SHA-256 on every launch and only re-downloads when it has actually changed;
• launches the Console, passing through any arguments — ariadne --headless, ariadne --acp, and so on;
• still starts your installed copy when the server can't be reached, so being offline doesn't stop you working.

Set ARIADNE_SERVICE_URL to point an existing install at a different instance. x64 hosts are served today; the script picks its bundle from uname -m, so an arm64 host reports that no bundle is published rather than installing the wrong one.

Windows

Download Ariadne.Launcher.exe from the same dialog. It does the equivalent job — installs under %LOCALAPPDATA%\Ariadne, self-updates, and starts the Desktop app; the CLI (Ariadne.exe) is installed alongside it and added to your PATH.

From source

dotnet run --project Ariadne.Console -- [options]

Code Mode Integration

Running the Console app is one of the primary ways to give Ariadne's Code conversation mode real file and terminal access. When a Console instance is connected to a Code conversation (or any conversation whose ID contains headless), the agent automatically discovers and uses the Console's local tool set — reading files, running builds and tests, and executing shell commands on the host machine.

See Code Mode & Remote Development Environments for a full explanation of how this works, including how to use Docker containers and how multiple clients can connect simultaneously.

Running Modes

Interactive Mode (Default)

dotnet run --project Ariadne.Console -- --conversation-id <id> --user "Your Name"

This opens a terminal-based UI where you can type messages and see the agent's responses. It works like the web UI but entirely in the terminal.

The window (and Windows Terminal tab) title reflects the session state, so you can find the right tab without reading any of them:

Windows Terminal additionally shows an animated progress indicator on the tab while work is running, and a warning-coloured one while a question is waiting — both visible when the window is in the background or minimised.

Headless Mode

dotnet run --project Ariadne.Console -- --conversation-id <id> --user "Your Name" --headless

In headless mode, the Console runs without an interactive UI — ideal for use in Docker containers or scripted automation. The working directory /app/work (when running in Docker) is mounted for persistent file access. No window title is set in this mode.

ACP Mode (IDE Integration)

dotnet run --project Ariadne.Console -- --acp

Or set the environment variable:

ARIADNE_ACP=true dotnet run --project Ariadne.Console

ACP mode enables deep integration with compatible IDEs. See ACP Integration below.

Connection Options

The Console connects to Ariadne via:

These can also be set in appsettings.json in the Console project directory.

Local File Tools

When running the Console (especially in headless mode), agents gain access to a rich set of local filesystem tools that operate on the host machine. These tools are only available via the Console — not through the web UI.

Local Semantic File Index

Ariadne maintains a local semantic index of the working directory, powered by an on-device embedding model. This means semantic search happens instantly without any network latency or API calls — queries are matched against an in-memory vector index that stays current as files change.

The index is built automatically by a background filesystem watcher, or manually via the Build File Index tool when working directory structure changes significantly (e.g. after a branch switch or rebase). Once indexed, any agent can use Search File Content (Semantic) with natural language queries like 'find the retry policy implementation' or 'where is the WebSocket handler for voice calls?' to locate relevant code chunks, even when they don't contain exact keyword matches.

This feature is particularly useful for large codebases where full-text search alone is insufficient, and it works entirely offline — no cloud dependencies or rate limits.

The /cd Navigation Command

In addition to programmatic tool calls, Ariadne supports a native /cd <path> command directly inside the Console terminal interface as well as web/desktop conversation inputs.

Typing /cd D:\Dev\MyProject (or a relative path like /cd ..) instantly updates the active working directory context for both your terminal session and any subsequent agent tool executions. This provides an intuitive, hands-on way to navigate your workspace alongside the agent.

Shell and Terminal Tools

Execute Program Details

The exec_program tool resolves commands automatically:

• Searches the system PATH
• Checks common directories (/usr/bin, /usr/local/bin, etc.)
• Provides clear error messages if a command is not found
• Captures both stdout and stderr
• Default timeout: 30 seconds (configurable up to 300 seconds)

This allows agents to run builds, tests, linters, and any other CLI tools available on the host.

Named Terminal Sessions

The terminal tool creates persistent named terminal sessions. This is useful for:

• Keeping a REPL open between agent turns
• Maintaining state across multiple commands (e.g. a Python interpreter session)
• Running a long-running process and interacting with it incrementally

Session: "python-repl"
> import pandas as pd
> df = pd.read_csv("data.csv")
> df.describe()   # (next agent turn — session remembers the state)

ACP (Agent Control Protocol) Integration

The Console's ACP mode integrates Ariadne directly into your IDE as a coding assistant. ACP is a JSON-RPC 2.0 protocol that IDEs use to communicate with AI coding agents.

Supported IDEs

Any IDE that supports the Agent Control Protocol can connect to Ariadne via the Console in ACP mode, including:

• JetBrains Rider / IntelliJ IDEA (and other JetBrains IDEs)
• VS Code (with a compatible ACP extension)
• Other ACP-compatible editors

What ACP Provides

When connected via ACP, the IDE gains:

ACP Method Reference

Setting Up ACP in Your IDE

1. Start the Console in ACP mode: dotnet run --project Ariadne.Console -- --acp (or set ARIADNE_ACP=true)
2. In your IDE, configure the AI assistant to connect to the Ariadne ACP server
3. The IDE will discover available capabilities (filesystem, terminal) and route them through the Console

Refer to your IDE's documentation for the specific steps to connect to an external ACP agent.

Remote File Editing

When the Console is connected to a conversation, you can edit files on the remote host directly from the web UI or Desktop app. If the agent is stuck on a coding task — for example, it cannot resolve a build error — you can open the file browser, make the fix yourself, and the agent will pick up the change on its next turn. This is particularly useful in paired programming scenarios where you want to nudge the agent in the right direction without typing instructions.

MCP Server Hosting

The Console can host MCP (Model Context Protocol) servers locally. This allows you to run MCP-compatible tools on your own machine and make them available to Ariadne agents.

dotnet run --project Ariadne.Console -- --mcp-server "path/to/mcp-server"

MCP servers started via the Console are registered with the connected Ariadne instance and are available to agents for the duration of the Console session.

Docker Usage

When running the Console in a Docker container (common in headless mode), the working directory is typically mounted at /app/work:

volumes:
  - /path/to/work:/app/work

All file operations by the agent are relative to this working directory by default, providing a clean, sandboxed workspace.

Configuration

The Console reads configuration from appsettings.json in its working directory, or from environment variables: