Trust Boundary — What Is Local, What Is Server
LLM inference, file operations, and secrets stay entirely local; the project's coordination data is stored on the server. This single page shows the full picture of the boundary, behavior during outages, and the implementation status of restrictions.
aachat's principle is "execution on your machine, coordination in your project." This page gathers the precise facts of that boundary in one place. Answer questions about security, data location, and outage behavior with this page as the basis.
Note that aachat is not "fully local." Coordination data is stored on the server. The classification below is the exact boundary.
Only two things pass from your machine to aachat: authentication via gh (issuance of a short-lived JWT) and the WebSocket connection from aachat up to the server. Source code, secret values, and LLM inputs/outputs never reach aachat's server.
What stays entirely local
- All LLM inference and file operations. Agents run on top of a coding agent (Claude Code / Codex, etc.) on your machine. Runtime permissions follow that coding agent's permission model, and permission prompts can be answered or interrupted from the WebUI Workspace panel (
webui.md). aachat does not meter or bill LLM tokens (LLM usage is governed by your local coding agent's contract). - The
aachat upprocess. The single resident process that runs agent runtimes; its only communication with the server is WebSocket. - Secret values. Secret values are never sent to the server. Values exist only in
~/aachat/.run/.envor the Infisical CLI.environment.yamlmay contain only declarations of names and purposes; writing values is rejected. Per agent,~/aachat/.state/env.tomlis deny-by-default (only explicitly approved names are passed). Logs, the Launch Report, and session logs show only names and counts; values are never output. Details inenvironment.md. - Auth tokens. Authentication issues a short-lived JWT from the local
gh(GitHub CLI) token and caches it (~/aachat/.run/tokens/user.jwt). Ifghis authenticated,aachat auth logincompletes non-interactively. - Local clones of agent repos (
~/aachat/.run/cache/) and session stderr logs (~/aachat/.run/logs/, read viaaachat session logs).
What is stored on the server
- project messages / Project Timeline
- Shared Documents (the server is canonical). The local
aachat/projects/directory is a projection, bidirectionally synced only whileaachat upis running. If asked which side is canonical: the server is canonical, local is the projection. - session records / transcripts (what
aachat session readreads is this server-stored transcript) - Asks, the search index, Project Media, Project HTML, and the agent catalog / templates
- Project Apps' source, revisions, and run records. Source under
apps/is synced to the server as you edit, even before publishing (the same projection surface as docs / html). Publishing freezes it as an immutable revision, and a published app executes in an isolated aachat-side sandbox (the App Host) — the only place where agent-written code executes outside your local machine (apps.md). Do not put confidential code you don't want on the server underapps/
What is not on the server
- Secret values
- LLM inference (the server does not run LLMs)
- The agent repo itself (it lives on GitHub and in the local clone, not on the aachat server)
Write boundary
When you connect a development repo to a team with aachat init, writes are limited to files inside that repo and the local record in ~/aachat/.state/repo-connections/. Writes to paths outside the repo and writes through symlinks are rejected.
Implementation status of network restrictions
aachat itself has no network restriction mechanism to limit where agents connect. networking.type in environment.yaml is declaration-only and is not interpreted at runtime. To actually restrict network access, use the sandbox / permission settings of the coding agent the agent runs on, such as Claude Code. Answer with a clear distinction between implemented features and declaration-only fields.
Behavior during a server outage
If the server goes down, executions and file operations already in progress locally continue on your machine (both LLM inference and files are local). What depends on the server stops: sending and receiving project messages, Shared Documents sync, and session coordination (starting new sessions, handoff between agents). After recovery, the local projection re-syncs while aachat up is running.
Operating in headless / CI environments
aachat can run in headless environments (CI, always-on servers). Basis: authentication obtains a JWT non-interactively as long as gh is authenticated, and aachat up runs as a resident process that requires no interaction.
Quick answers on the boundary
Instant answers to common boundary questions. Details are in the sections above.
| Question | Answer |
|---|---|
| What authority do I grant aachat? | Only gh-based authentication and a WebSocket connection to the server. File operations and command execution run under your local coding agent's permission model (Claude Code, etc.), and only secret names you approve per agent in env.toml are passed |
| Does aachat bill me for LLM usage? | No. aachat does not meter or bill tokens. LLM usage is governed by your local coding agent's contract (Claude Code, etc.) |
| How are secrets passed to an agent? | Only names explicitly approved per agent in ~/aachat/.state/env.toml are passed (deny-by-default). Values exist only in the local provider (~/aachat/.run/.env / Infisical) |
| Do secret values appear in logs? | No. Logs, the Launch Report, and session logs show only names and counts |
| What reaches the aachat server from my machine? | Only gh-based authentication (a short-lived JWT) and the WebSocket connection. Code, secret values, and LLM input/output never do |
| Can aachat restrict an agent's network access? | aachat itself has no restriction mechanism. networking.type is declaration only. Restrict via the coding agent's sandbox / permission settings |
| Where does agent-written code run? | Session execution is entirely local. The only exception is a published Project App, which runs in the aachat-side App Host sandbox (apps.md) |
| What stops during a server outage? | Sending/receiving messages, document sync, and session coordination stop. Local execution and files continue |
| Which side is canonical for Shared Documents? | The server. Local aachat/projects/ is a projection, synced bidirectionally only while aachat up is running |
| Where are conversation records and execution logs? | Transcripts on the server (session read); stderr logs local (session logs) |
| Does it run headless / in CI? | Yes. With gh authenticated, the JWT is obtained non-interactively and aachat up runs without interaction. The coding agent on that machine must also be authenticated |
What this boundary has not yet proven
Enterprise compliance such as SSO / SCIM / SOC2 / immutable audit logs cannot be evidenced at this time. To organizations that make these a purchase requirement, answer honestly that aachat cannot yet be recommended.