
PART 1Start and understand1.5
Trust Boundary — What Is Local, What Is Server
This page is the single source for execution, stored data, secrets, transport, inbound input between Sessions, and outage boundaries across the local agent runtime, viewer browsers, and the aachat server.
Agent processes and file operations run on the execution machine; the aachat server shares and stores Project documents, conversations, and execution records. That does not mean "fully local" or "the server stores metadata only." Use this page as the source of truth for security, data location, transport, and outage behavior.
There are three execution and storage layers.
| Layer | Execution and storage |
|---|---|
| local agent runtime | Claude Code / Codex and file operations, raw inference traffic with the LLM provider, session environment secrets, workspace repos |
| Project HTML viewer browser | JavaScript in a project's html/ runs in the browser of each member or public-share viewer who opens it |
| aachat server | Project messages and execution records, Shared Documents, session transcripts, Project Media / HTML, credentials and access control |
local agent runtime
- Coding-agent processes and workspace file and command operations run on the owner's machine. The local runtime connects to the LLM provider, where inference happens. Permissions follow the Claude Code / Codex model; you can allow, deny, or interrupt from the Workspace panel in WebUI
- Raw inference traffic with the LLM provider comes from the local runtime. aachat does not run the LLM and does not meter or bill tokens
- Ordinary workspace repo and agent repo contents are not uploaded to the aachat server to run sessions. The exceptions are the explicit project projections
docs/,media/, andhtml/, and operations on the Project Database - Session environment secret values live in the selected computer's login Keychain or
.env. Only declared names bound per Agent to that destination in.state/env.tomlreach sessions (Environment) - Agent repos live on GitHub and in local clones, not on the aachat server. The exception is Discover publication preparation: the source and public text of files selected for review are stored for private review (see below). The
aachat uplog (~/aachat/.run/logs/up.log) and session stderr logs are also local under~/aachat/.run/logs/ - The CLI user JWT is at
~/aachat/.run/tokens/user.jwt. The macOS Desktop 1.0 guide operates the ordinary CLI to prepare and start aachat, and the CLI uses the same files to make authentication and runtime state decisions. The only authentication the app itself handles is sign-in for the guide runtime (Claude Code / Codex) (Desktop)
Input boundary between Sessions
Input to an aachat Session arrives through aachat routes (Project messages, delegation, chat session send, and so on) and is handled according to the Session's Project coverage.
For the Claude runtime, aachat pins "crossSessionInbound": "refuse" in each agent workspace's .claude/settings.local.json. Any existing value is overwritten, and a user-level accept cannot loosen it. As a result, another Claude Code session on the same machine and OS user cannot inject turns directly into an aachat Session. SendMessage to subagents within a Session is not affected.
What is sent to and stored on the aachat server
The local runtime does not use only WebSocket. It uses WebSocket for real-time runtime control and delivery, and HTTPS APIs for persistence and project operations.
- Project messages, Project Chat, Asks, search indexes, membership, and roles
- Shared Documents. The server is canonical; local
aachat/teams/<team>/projects/<project>/is a projection synced whileaachat upruns. In a Session worktree, the Session's own mirror syncs the projected files, not theaachat updaemon. Deleting a projected file normally also deletes the server document (except deleting or moving a file that is in conflict; see Shared Documents) - Session records and transcripts. User / agent messages, display representations of reasoning and tool calls, and session events including execution config and usage are persisted to the server. This does not mean raw LLM provider traffic passes through the server
- Live view. While a Session pane is open, in-progress messages and tool-call summaries flow through the server to the browser
- Project Media, and Project HTML sources and delivery snapshots
- Agent catalog, skills / Skill Ledger, templates, Company model (Concept / Entity)
- Webhook Trigger settings and secret hashes (Triggers)
- Private publication reviews. When you prepare a publication in Discover, the source and public text shown for review are stored in an owner-scoped private area. Excluded files are shown only by path and reason; their contents are not uploaded, even for review. Writing to the public GitHub repository and listing in Discover happen only when you select Publish this content
- Diagnostics for operational failures. The CLI and runtime send only identifiers and classifications, such as Session / Project IDs, command, error category, and duration, to aachat's error monitoring. They do not include conversation text, request / response bodies, Team / Project / user names, email, or IP
A whole development repo connected with aachat init is never stored on the server. Keep confidential code you do not want on the server out of a project's html/, docs/, and media/.
Tool input and output
The live view and newly saved permanent Session history treat tool calls as summaries. A summary contains the ID, kind, status, name, title, input, and the paths of files the tool touched. For supported completed tool output, the local runtime retains and sends only the last 2,000 Unicode characters as plain text in the summary. This tail can appear in both the live view and newly saved permanent history. Full raw output and diff text are not retained. Size limits may also cause omissions, so full input storage is not guaranteed either. Conversation text, Shared Documents, and other records are still stored, and this policy does not guarantee deletion of older history or other storage locations. See Sessions for how to keep results you need later.
Secrets and external credentials
| Kind | Storage location | Who receives it |
|---|---|---|
| Session environment secret | The selected computer's login Keychain / .env | Local agent sessions whose names are approved in env.toml |
| CLI user JWT | The owner's ~/aachat/.run/tokens/user.jwt | The aachat CLI and runtime on that machine |
| Webhook Trigger secret | Only a hash on the server | Used to authenticate external starts |
Tools > Secrets sends entered values over HTTPS/WSS through the server to the human owner's selected HostMirror. Values exist transiently in browser, server, and host memory during this operation; this is not end-to-end encryption against the server. Saved values are not returned by inspection or persisted as server-side secret records. The list contains metadata only. Old settings require explicit human terminal adoption before WebUI may expose their names or destinations. Agent tokens cannot manage Tools secrets.
There is a contract not to intentionally write secret values to logs, but nothing automatically guarantees that local agent code will not send a value it received elsewhere. Minimize approved secrets after checking the code that runs and its permission boundary.
A Webhook Trigger Bearer secret authenticates external starts of its configured target, and the server stores a secret hash. It is separate from secrets injected into workloads; manage it in Triggers.
Project HTML viewer browser
Project HTML sources and delivery snapshots are stored on the server, but authored JavaScript runs in the browser of each member or public-share viewer. The delivery security headers use CSP to deny frame embedding, objects, base URL changes, ordinary forms, and Workers, and Permissions-Policy to disable device APIs such as camera, microphone, and geolocation. CSP does not define script-src or connect-src, so scripts can run and make network requests under normal browser rules. Review generated HTML before opening or sharing it, and never embed secrets or privileged credentials (HTML).
In member previews, HTML scripts (including external scripts) can use the Database API to read and write the same Project's data with the viewer's current Project permissions. Public shares cannot use this API. Save controls and retry behavior are the HTML author's responsibility.
Database operations from preview are for Human members. Agents use the existing Session Database API, which checks their own running Session and current coverage. Agents can still view HTML and Media.
Authentication and writes
- CLI authentication uses the local
ghtoken to issue a short-lived JWT and caches it at~/aachat/.run/tokens/user.jwt. The GitHub token itself is not stored in projects - Older macOS Desktop 0.x GitHub sign-in uses OAuth with PKCE, returns from the browser to the app through an
aachat://callback, and the CLI saves the JWT in the same place. The GitHub scopes requested areread:useranduser:email. Desktop 1.0 does not use this path; the guide helps you prepare ordinary CLI authentication through conversation aachat initwrites only inside the connected repo and~/aachat/.state/repo-connections/. Writes to paths outside the repo or through symlinks are rejected- Each member using a team default workspace repo needs their own GitHub credential, repo read/write access, and organization SSO authorization where required. aachat does not grant repository access (Teams)
During a server outage
An already-running coding agent can continue local file operations and provider requests during an aachat server outage, provided its runtime, network, and LLM provider remain available. HTTPS API / WebSocket-dependent transcript persistence, the live view, messages, Shared Documents sync, new session starts, follow-ups, and handoffs stop. Project projections re-sync after recovery while aachat up is running.
Guarantees not implemented or evidenced
- aachat has no mechanism that restricts a local agent runtime's network destinations.
networking.typeinenvironment.yamlis declaration-only. Use the Claude Code / Codex sandbox and permissions when restrictions are required - Current public documentation does not evidence SSO / SCIM / SOC2 / immutable audit logs or a complete retention and deletion guarantee for server data. Do not promise them
Structured data and public access
Project Database rows live in a server-managed Cloudflare D1 database for each ordinary Project. Server-side Postgres holds its metadata and schema cache; db/schema.sql is a read-only local projection and db/migrations/ contains migration sources. This is another explicit Project data surface: local migration sync does not execute SQL, and editing workspace code does not automatically upload it into the database. A running covered Session uses role-checked server operations. The WebUI table browser is read-only.
New database operations stop when the Project is no longer active. Accepted work can finish, and Project deletion waits for query leases, migration reconciliation, and physical database deletion. A deleted local file is neither a rollback nor proof of server erasure.
Public shares deliberately cross the membership boundary. Anyone with a valid Markdown token can read its scope without logging in. A document token reads the current document and authorized media dependencies; an Admin-created context token can read Project records, documents, and Project session transcripts, including later content. These are live reads, not immutable exports. WebUI links last 7 days; authorized creators/Admins can revoke them as described in Sharing. Copies already downloaded cannot be recalled.
Media /m/<uuid> URLs still require membership unless access is delivered through an authorized share dependency. Share HTML exposes a built static surface with an expiry of 1, 7, or 30 days and an optional password. Its JavaScript executes in the recipient's browser and does not grant the author's server credentials or database access. Before publishing, inspect both content and dependencies and choose the smallest suitable sharing scope.
Quick answers
| Question | Answer |
|---|---|
| Where does the LLM run? | At the LLM provider reached by the local Claude Code / Codex runtime; the client process runs on the owner's machine |
| Does session conversation reach the server? | Yes. The transcript, display representations of reasoning/tool calls, and execution metadata are persisted over HTTPS. Supported completed tool output includes only its last 2,000 Unicode characters in the live view and new permanent history |
| Is WebSocket the only transport? | No. WebSocket is for real-time control; HTTPS APIs persist and operate on projects |
| Are all secrets local? | Session environment secrets and the CLI JWT are local. Webhook Trigger secret hashes are stored on the server |
| What is canonical for Shared Documents? | The server. Local aachat/teams/<team>/projects/<project>/ is a projection |
| Where does agent-written code run? | Session code is local; Project HTML JavaScript runs in each viewer's browser |
| Where are conversation and execution logs? | Transcript on the server via session read; stderr local via session logs; the whole runtime's log locally in up.log |
| Can another Claude Code session send input into an aachat Session? | No. crossSessionInbound is pinned to refuse. Use aachat routes |
| What stops in a server outage? | Persistence, sync, the live view, messages, and session coordination. Existing runtime file operations and provider requests can continue if those dependencies remain available |