Skip to content
AASC
中文
Documentation pages

Central Sessions

Start a session that can see and steer your other sessions, with rules that keep you in control.

What a Central Session Is

A central session is a session that AASC starts with one extra MCP server, named aasc. Through that server the session can see your other sessions, hand work to them, and answer their questions. It runs Claude Code or Codex like any other session. It has a terminal, a card, and a ★ badge in its header.

Use one when you want an agent to look after your other agents. For example, ask it what everyone is working on. Or ask it to split a job across three sessions and report back.

A central cannot do whatever it likes. It stays inside its scope. It follows rules that protect your sessions. Anything destructive, and anything that leaves your computer, waits for your yes.

Central sessions are off by default from AASC 2.10.60. Turn on Central sessions (MCP) in Settings, ADVANCED, then restart AASC.

The Three Kinds

  • Global. One for your computer. It sees every session.
  • Room. One per room. It sees the sessions its room lists, and the sessions it opened itself.
  • Project. One per project folder. It sees the sessions on your computer that work in that folder or below it.

A scope has at most one central. A call about a session outside the central's scope is refused, and the refusal says nothing more about that session.

Some of your own data is not tied to a session: Library resources, saved prompts, skill notes, notes, the agenda and plan usage. A central that has the matching tools can read all of it, whatever its scope.

Start One

  1. If you have not yet, turn on Central sessions (MCP) in Settings, ADVANCED, and restart AASC.
  2. Open the New Terminal Session form. Click + in the session panel, or + NEW on the empty LIVE page.
  3. Fill in the working directory and a command. The command must be a bare claude or codex. A title and a room are optional.
  4. Set Central session to Global, This room or This project. The default is Off, and the choice goes back to Off each time you open the form.
  5. Click CREATE.

This room appears only when you chose a room in the form. This project appears only when the form has a working directory. A scope that already has a central is greyed out, with a note.

These rules apply:

  • You can start a central only from the dashboard on your own computer. The phone app has no picker, and the server refuses a central asked for by any other device.
  • A central runs on your computer. It cannot run on a remote SSH host or inside tmux.
  • A path, a quoted word, npx claude and FOO=1 claude are refused. Use a bare claude or codex.
  • A project central needs a project folder. /, your home folder and the folders above it are refused, because they would take in every session.
  • A room central needs a room that exists.
  • A fork or a floating AI popup is never a central, and a central cannot start another central.

When you restart, resume or reconnect a central, or restore your workspace, it comes back as the same central with a new token. If it cannot, for example because its room is gone or another central holds its scope, it starts as a plain session. The server log says why.

The badge in the session header reads ★ global, ★ room with the room's name, or ★ project with the folder's name. When the central has opened sessions of its own, the badge also shows how many.

What a Central Can Do

Read

  • The session list, with status, title, folder and model, and the details of one session.
  • A session's conversation, its last answer, the files it changed with their diffs, its subagent runs, and its terminal output.
  • Prompt queues, requests that wait for you, rooms, History, Library resources, saved prompts, notes, the agenda and plan usage.

Reading needs only scope. Reads are not logged. Text that a session wrote reaches the central marked as data to read, not as instructions to follow.

Hand a task to a session

The central gives a session a task. AASC types it into the session as a message that begins with a line such as [AASC · task T12 from ★ global], so the session knows who sent it. AASC then follows the task from the prompt to the session's answer.

A task moves through these states: queued, sent, running and done. It can also end failed or cancelled. It can be blocked while the session waits for you, or stalled when an API error ends the turn. The central waits for the task and reads the answer, up to 20,000 characters. A session takes one central task at a time.

Send a prompt or a command

A central can type a prompt into up to 8 sessions at once. It can also run a slash command or skill. A short list of commands is never run, such as /clear, /exit, /login and /logout. Text that starts with ! would run as a shell line, so it is refused.

Open sessions

A central can start a new session in a folder. It can also resume, reconnect, fork and clone sessions. A session a central opens itself is its worker.

  • At most 8 workers are live at once, and at most 10 sessions are opened a minute.
  • A worker is never given a looser permission mode than the central has.
  • A central opens nothing while that CLI's 5-hour plan window is above 90 percent.
  • AASC closes an idle worker after 30 minutes. You can change that, see Settings.

Queue prompts

A central can add, edit, move and remove prompts and steps in a session's prompt queue. In a session it did not open, it cannot switch on anything that makes AASC type by itself: auto-send, auto-enter, auto-resume, a prompt that is switched on, or the NOW button. Only you can turn those on there.

Answer a session's dialog

A central can answer a dialog that waits in a session. It can allow once, deny, or pick an option. It never sends "always allow". It can answer only while the session still waits on that exact request.

Organise

A central can change titles, remarks, pins, mute and alert, and move sessions between rooms. It can also keep notes, saved prompts, the agenda, skill notes and Library aliases.

End things and use the cloud

A central can stop a running turn, restart, kill or close a session, clear a queue, uninstall a resource, and delete saved prompts, History rows, notes and agenda tasks. A global central can also work with AASC Cloud. All of these wait for your yes. See Confirm Cards.

Claude Code and Codex

A Claude Code central gets the full set of tools. It also gets resources and ready-made prompts such as status, triage and dispatch. By default a Codex central gets a smaller set of tools and no cloud tools. Codex shows its model the tools only.

The Rules That Protect Your Sessions

AASC checks these rules before a central types into a session, hands it a task, answers its dialog or edits its queue. A refusal never repeats what the central sent.

  • Scope. A session outside the central's scope is refused first.
  • Hands off. Each session has a Hands off button in its header, right after Pin. While it is on, no central types into that session, hands it a task or edits its queue. Centrals can still read it. Only you can turn it off, because a central's own calls to the switch are refused. Turning it on stops a task AASC is still typing. A task that is already running keeps going until it ends or you stop it.
  • You are typing. If you drove a session in the last 60 seconds, a central waits and is told how many seconds are left.
  • You pressed Esc. If you stopped a Claude Code session with Esc, a central cannot send to it until you prompt it again. A Codex session has no such hold.
  • One task at a time. A session that holds a central's task refuses another one until the first ends.
  • Some sessions are never steered. A central never steers itself, another central, a session's commands terminal, a subagent, a floating AI popup, an external card, a session on another machine, a session with no terminal, or an ended session.
  • Checks on every keystroke. While AASC types for a central, it checks Hands off, your activity and your Esc before each keystroke. It stops if you took over.

A central presses Esc only to cancel the turn of its own task, and only when these rules allow it.

Confirm Cards

Some actions are yours to decide. When a central asks for one, the call waits and a confirm card appears.

What waits for your yes

  • Stopping a running turn, and restarting, killing or closing a session. A central's own idle worker can be restarted or closed without a card when it is idle or waiting, not pinned, not on Hands off, holds no task, and has nothing switched on in its queue. Stopping the turn of its own worker needs no card either. A kill always asks.
  • Clearing a session's prompt queue.
  • Uninstalling a Library resource, and deleting a saved prompt, a History row, a note or an agenda task.
  • Turning sharing on for a session, and creating or renaming a saved prompt.
  • Anything that leaves your computer: AASC Cloud sync, publish, install, and project create, update, push and remove. Only a global central can do these.

How a card works

  • A card appears in the bottom-right corner of the dashboard window, above panels, dialogs and fullscreen terminals. Up to three show at once, and the rest read "+N more waiting".
  • It says which central asks, what it wants in AASC's own words, and which session it is about. It also shows the text the central wrote, as plain text.
  • Click Allow once or Deny. Allow once is disabled for a moment after a card appears, so a stray click cannot land on it. Escape does nothing on a card.
  • A card expires after 5 minutes, and an expired card counts as a no.
  • If you allow, the action runs once, with exactly what you saw. AASC checks again just before it runs. If the session, the queue or the cloud account changed after the card appeared, nothing runs and the central must ask again.
  • A central cannot answer its own card. The card's id goes only to your dashboard windows.
  • A dashboard window must be open on your computer. With none open, the central's call is refused, because nobody could see the card. The one exception is a card a paired phone can answer, while a paired phone is connected.
  • A central can have 3 cards waiting, and your computer 20.

On your phone

The AASC phone app is available for Android, and is coming to iPhone through TestFlight. In the app, cards for these actions also appear in the Inbox: stopping, restarting, killing or closing a session, clearing a queue, deleting a note or a saved prompt, and creating or renaming a saved prompt. The central and the session must both be shared with phones. Your phone is told when a card waits.

Everything else is answered on your computer only. That includes AASC Cloud changes, uninstalling a resource, deleting History or the agenda, and turning sharing on.

The ACTIVITY Tab

A central's detail panel has an ACTIVITY tab. It is the last tab, after AGENTS. It lists every change the central made, every refusal and every change in the state of a task it handed out.

Each row shows the time, the tool, the target session, the outcome, and a one-line summary in AASC's words. The outcome is ok, refused, failed, or the state a task moved to. The tab reads the newest 200 rows when it opens and follows new rows live.

The log holds AASC's own words, ids and codes. It never holds a prompt, a path, text a session wrote, or a task's answer. Rows are kept for 30 days. The tab is not in pop-out windows.

A session that works on a central's task shows a chip on its card, such as ← ★ global · T12 · running. It goes away when the task ends.

The Token

Each central has a bearer token. It lets the central's CLI call AASC's /mcp endpoint, which is served on the dashboard's port. The endpoint accepts only requests from your own computer, with a live central's token.

The token lives only in the environment of that central's terminal, as AASC_MCP_TOKEN. It is not on the command line. Claude gets the text ${AASC_MCP_TOKEN} in its --mcp-config flag and expands it itself. Codex gets the variable's name, not its value. The token is never in a stored command, a log, a workspace snapshot, the database or any dashboard feed.

AASC keeps tokens in memory only. A token stops working when its terminal exits. When AASC restarts, every token is gone, and restoring your workspace mints new ones.

Automatic Routing

A central can hand a task to a session you name. It can also ask AASC to choose, with to: "auto". AASC then reuses a fitting idle session or opens a new one.

Automatic routing is off by default. In a replay of real first prompts, it chose the right project for 13 of 31, about 42 percent. That is below the 70 percent bar set for turning it on. With routing off, a central that asks for auto gets an answer that automatic routing is off, so it has to name the sessions.

A central can still ask where AASC would send a task. The task_route and project_resolve tools show the decision and send nothing. They work with routing off.

To turn automatic routing on, set autoRouting in the mcp settings and restart AASC.

Settings

Central sessions are off by default from 2.10.60 (they were on before). The switch is Central sessions (MCP) in Settings, ADVANCED. AASC saves your choice at once and applies it the next time it starts. The other settings go in server-config.json. See Configuration for where the file is.

{
  "mcp": {
    "enabled": true,
    "autoRouting": false,
    "idleWorkerMinutes": 30,
    "notices": false
  }
}
  • enabled: read only until you use the switch in Settings, which then wins. Off unless it is true. While central sessions are off, /mcp is not served, a new central is refused, and the Central session picker, the Hands off button and the ACTIVITY tab are hidden.
  • autoRouting: whether to: "auto" works. Default false.
  • idleWorkerMinutes: how long a worker may sit idle before AASC closes it. Default 30. Use 0 to never close workers.
  • notices: when true, AASC types one [AASC · notice] line into an idle central about its ended tasks and about confirmations answered late. Default false, because each notice starts a model turn.

AASC reads these settings once, when it starts. Restart it after you change them.