Get to know Astera.

Start with one project and one account. You can explore automation after your first conversation is running.

1. Install Astera and your agent

   Use the Download button to get the installer for your operating system. You also need Claude Code, the Codex CLI, or both installed and available on your PATH, so Astera can start them.

   Astera runs your existing tools. Accounts and any usage fees for those services are separate.

   Platform-specific installation steps

2. Connect an account

   In Accounts, use Auto-detect to find existing accounts and register the ones you want. Or choose Add account to create a separate account entry, then complete its sign-in when prompted.

3. Choose your folder and session type

   Open New session. Select your Project folder and Account, choose Terminal or Chat, then click Start. A folder keeps the conversation connected to the code you are working on.

4. Give the agent a clear first task

   Describe the result you want and how to check it. For a first look at an unfamiliar project, try:

   Explain how this project is organized and how to run it locally. Don’t change any files yet.

   Read the response, answer any questions, and continue in the same session.

Both give you a session with your agent. Choose the interface that feels natural for the work you are doing.

Explore the actual app

Terminal viewChat view

Take a closer look

Tabs shrink until about half a name remains, then scroll, including with the mouse wheel. Korean terminal input no longer doubles or loses words while the app is busy. Text sent from the CLI, browser pane, or Slack waits until the session has drawn it before Enter is sent.

Account rolling moves a session to another available account for the same service when it reaches a usage limit. With the standard resume strategy, the conversation continues on that account.

1. Register and sign in to the accounts you want to use.
2. In New session, choose the first account. Use + Add account to set the next accounts in the rolling order.
3. Start the session. Astera watches for a limit and switches when another account is available.

When adding an account, Import settings from the default account brings over its setup. Codex settings merge into config.toml, preserving comments and unrelated entries. Once items are registered in MCP & Skills, that screen manages them instead of copying them again. Changes apply to new sessions.

Watch full demo

In Settings → MCP & Skills, click Add, choose an account, and select its MCP servers, skills, commands, and agents to share. New sessions get them across accounts, rolled sessions included. Provider support still applies: Codex has no slash commands or subagents.

File copies are kept in step across accounts. A removed managed copy is restored; an edited copy is backed up before restoring. An account’s own different copy stays until you choose Replace with shared version. Expand an item to inspect its status, turn it off, or remove it.

A shared local MCP server runs once per project folder through the Host’s Gateway, stops after five idle minutes, and restarts when needed after a crash. Tick Run per session when sessions need separate state. Browser servers such as Playwright and chrome-devtools use that mode by default, with a browser profile per session.

astera ext list
astera ext sync

These work with the app and Host closed: ext list inspects shared entries; ext sync synchronizes file copies. Astera’s bundled skills use the separate skills list and skills install commands. Sharing tools with sessions is separate from connecting a client to Astera over MCP.

Open Settings → Agent profiles → New profile. Name it, add accounts from one provider in rolling order, choose which shared MCP servers to leave out, and select permission checks: follow the app setting, always ask, or run without checks. Skills and commands stay shared across profiles.

Pick the profile in New session, when creating a Job, or when adding a Task. Tasks follow their Job’s profile unless you choose another; the coordinator account is selected separately. Rolling keeps the profile, and History’s resume dialog remembers and names the conversation’s profile.

astera agent-profiles list
astera agent-profiles show --id PROFILE_ID

Use an ID or name from the list. Your own shell can also create, update, archive, and restore profiles. MCP reads list_agent_profiles and selects agentProfileId when creating work. Client SDK 0.5.0 adds agentProfiles.list and agentProfiles.get. Agents cannot edit profiles. Agents, MCP clients, and plugins may use a profile without permission checks only while the app allows that mode.

In Settings → Security & Access, Record agent tool calls starts Off. Choose Observe and start new sessions to record calls without blocking them. Audit Logs lists calls by day; Policies holds ordered Rules showing what would be allowed or denied. The coverage table explains what each provider and session type can see.

Records keep the action, a short target, read/write effects, and the name of a login folder touched. They never keep full commands, output, or file contents, and are retained for 30 days within size limits. Run detail links to that Run’s Audit Logs.

Choose Enforce to stop calls the Rules deny and record them as blocked. Review what the last seven days would have hit before enabling it. It adds about 0.1 seconds per call and needs Claude Code 2.1.306+ or Codex 0.160.0+; a session that cannot be protected does not start. Enforce always protects Astera’s settings folder and settings-changing commands.

Under Credentials, shared MCP keys appear automatically. Add environment variable names or CLI login presets (gh, AWS, Google Cloud, npm, Docker, kubectl) for every project or chosen projects. New sessions and completion checks do not receive hidden credentials; check results name hidden variables. Astera’s GitHub and Gateway credential uses appear in Audit Logs. Hiding does not prevent programs running as you from reading login files or OS stores.

astera policies show
astera audit list --run RUN_ID
astera credentials list
astera credentials doctor

Use an actual RUN_ID, or omit --run RUN_ID for all calls. These commands need a running Host. Audit history is for a person; agents can read policy and credential descriptions but cannot read audit history or change their own protection. Edit Credentials in the app.

In an agent profile, enable Run in the sandbox, off by default, then start a new Terminal or Chat session. Codex needs 0.160.0+. On Windows each Codex account needs a one-time Set up, which shows an administrator prompt. If its config.toml still makes the elevated sandbox the default, Settings and sandboxed starts name the account and offer to remove that setting.

Codex, and Claude Code on macOS and Linux, use their own sandboxes to limit writes to work and temporary folders and restrict access to login folders and OS secret stores. The network stays available. Claude Code has no sandbox on Windows: only its file tools are kept out of login folders; its shell stays unrestricted. Codex on Linux blocks file-path session buses, not abstract sockets; Claude’s OS-store coverage was measured on its sandbox runtime. Read What the sandbox blocks in Security & Access for platform coverage.

A marked sandboxed session cannot hand work to sessions, Jobs, or Tasks outside the sandbox, call the Host directly, or write Astera’s profile or installed code. Its agent browser has an empty page store of its own. A warning identifies a work folder containing your home folder or a Claude shell that cannot run on Ubuntu.

Open Settings → Security & Access → Findings for unused or duplicate profiles, removed accounts or servers still referenced, repeated failures, unused tools or credentials, access broader than recorded use, partly covered Rules, long-unreached Runtimes, and unusually costly Runs. Each finding explains where to act. Nothing changes automatically; Ignore sets it aside.

Unused profiles need 90 days. Unused MCP servers, skills, commands, agents, and over-broad profile findings need 30 days of Observe history; failure and token-spike findings use separate records and do not wait for Observe. An unreadable source is identified rather than treated as clean. Profiles show open findings. Archiving records when and why; scheduled Jobs using that profile wait until it is restored, while work already holding it continues.

astera agent-profiles audit

The CLI reads the same findings from a running Host. Agents may read them but cannot ignore them. Expected extensions missing or different on a Remote Runtime, and an older Astera there, also appear with the snapshot time.

Use Smart Resume when an account switch should give the next session a focused handoff. Standard resume continues the existing conversation. Smart Resume starts a fresh conversation with a compact checkpoint of the work so far.

1. In Settings → General → Session resume strategy, choose Smart Resume. It is off by default.
2. Set up your account rolling order. A limit-triggered switch to an available account for the same service uses the checkpoint.
3. Continue in the session. The next agent receives the checkpoint as its first message and can inspect the working files to pick up the task.

Use the scheduler for recurring work, such as checking a test suite every morning or asking for a regular project update.

1. In New session, enable Scheduler.
2. Choose an interval, or a daily, weekly, or monthly schedule.
3. Enter the command for a Terminal session, or the prompt for a Chat session. Start the session to activate it.

Keep Astera running and your computer awake for scheduled work. A scheduled session sends work to one conversation. For a sequence of dependent tasks, use Jobs.

Watch full demo

Receive progress updates when a turn finishes, an account reaches a limit, or your input is needed. With bot mode configured, each session has its own thread. Reply in that thread to send a message back to the session.

1. Create a Slack app and invite its bot to your notification channel.
2. Enter the bot token and channel ID in Astera’s Slack settings. For replies, also configure Socket Mode, its app token, and your Slack member ID.
3. Turn on Slack progress notifications for the session.

A Job turns an objective into a graph of tasks. Its connections show what can run in parallel and what must wait. Follow Claude and Codex workers, questions, and completion checks from the same run.

Run detail and each Task show token totals read from Claude and Codex session records. Use the Audit Logs link to inspect recorded tool calls after enabling Observe.

1. Use a git repository with at least one commit and a branch checked out.
2. Open Jobs → New job. Enter the Objective, choose a Coordinator account, and set Run at once.
3. Add tasks, worker accounts, and dependencies. Attach build, test, or cross-vendor review checks. Enable Auto-fix until the checks pass if you want repair attempts within the retry limit.
4. Click Run. Follow the graph, answer questions, and review the finished work. For a normal Job, click Merge when you are ready to bring it into your project.

Watch full demo

Make a Job from an open GitHub issue or a ticket supplied by a job-source plugin. Astera carries the source material into the objective, names the Job after the ticket, and keeps a link back to it.

1. Select your local git project in Jobs, then click + From a source. The repository needs a commit and a checked-out branch, just like other Jobs.
2. Choose a source, search its items, and select one to read its description and fields. More loads the next page. Job exists opens a Job already made from that item; making another is allowed.
3. Choose a Coordinator account and, if wanted, enable automatic repair. Click Make the job, review the saved Job, then click Run when ready. Creating it does not start execution.

astera projects list --human
astera sources list --human
astera sources items --source github --project PROJECT_ID --human
astera sources show --source github --item 12 --project PROJECT_ID --human
astera jobs create-from-source --source github --item 12 --project PROJECT_ID --coordinator-account ACCOUNT_ID
astera jobs run --id JOB_ID

A Job can carry its work through a pull request, GitHub CI, repair, and a second agent’s review. Enable it for the Job you want to take through GitHub. Astera tells you when it is merge-ready; you merge it yourself on GitHub.

Turn it on for a Job

1. In Jobs → New job or + From a source, tick Carry it through GitHub. It is off by default. Enabling it also enables automatic repair.
2. The Host checks that origin is a GitHub repository, gh is signed in, and your repository permission is WRITE, MAINTAIN, or ADMIN. If a check fails, creation is blocked with its reason.
3. In Settings → GitHub, choose whether to rerun CI failures outside the code, the rerun limit (1 to 10), and the CI wait limit (10 to 1440 minutes). New Jobs copy these defaults; changing Settings does not change existing Jobs.

What happens after the Tasks finish

1. Astera adds a Carry to GitHub Task without a worker. It gathers the Tasks’ results on the Run’s branch, reruns local checks, and pushes. It opens a draft PR or binds an existing open PR. A Job from an issue in the same repository adds Refs #N to the PR body.
2. It waits for CI on the head it pushed. Required branch checks decide the result, alongside any checks you selected with --github-checks. If neither is specified, all reported checks decide.
3. For test, build, lint, or type-check failures, an agent receives the failed job’s log and repairs the Run’s branch. Local checks run again before the fix is pushed and CI is checked again, within the automatic repair budget. Network or runner failures can be rerun within the GitHub settings limit.
4. After CI passes, a reviewer from a different provider than the last implementer reviews the whole PR, including whether the change weakened CI. A passing review makes the Run merge-ready for that reviewed commit.

Follow progress and answer questions

The Job card shows waiting for CI, repairing CI, or merge-ready. Open the Run’s GitHub section for the PR, head, checks, failure reasons, repairs, Astera review, GitHub’s own state, and when merge-ready was decided. The timeline records each step; How It Works keeps the issue, PR, and GitHub evidence.

Astera asks when no CI appears, the wait limit is reached, someone else pushes, several PRs are open, the PR closes or merges, a failure is outside the code, or GitHub delivery cannot continue. Read the question and choose whether to wait, proceed without CI, accept the head, retry, rerun, bind a PR, or mark the Task failed. The Host handles your answer; if it is down, start it first.

Use the CLI, MCP, or SDK

Add --github-lifecycle when creating a Job with the CLI. After the Carry to GitHub Task has ended, successfully or not, use runs reconverge to carry the Run through again. It refuses a closed or merged PR, or a missing Run worktree. Replace the placeholders with your account, repository path, Job ID, and Run ID.

astera jobs create --objective "Improve the sign-in flow" --cwd "REPO_PATH" --coordinator-account ACCOUNT_ID --github-lifecycle
astera jobs run --id JOB_ID
astera runs follow --id RUN_ID --human
astera runs reconverge --id RUN_ID

MCP uses githubLifecycle on create_job and reconverge_run. Creation needs Read and control and Let MCP clients act on GitHub in Settings → CLI. Selecting additional checks is available through CLI and MCP. @astera-app/client 0.4.0 also reads and answers the lifecycle state.

See the GitHub lifecycle reference for the full flow, questions, and recovery conditions.

A completion-check plugin can check a Task's changes and return a summary, findings with file names and line numbers, and a report link. For example, the debug-leftovers sample finds added console logs, debuggers, TODOs, and FIXMEs.

1. Install and enable a trusted check plugin in Settings → Plugins. Installing it does not attach it to any Task.
2. When adding a local Task, choose its plugin checks beside the run configurations. With the CLI, use plugin:PLUGIN_ID in --validate, using the ID from astera plugins list. Multiple checks run in the listed order and stop at the first failure.
3. After the worker reports done, open the Task's completion details for its summary, findings, and report link. With automatic repair enabled, a failed check sends those findings back to the worker within the Job's repair limit.

astera plugins list --human
astera tasks add --job JOB_ID --account ACCOUNT_ID --spec "Implement the change and verify it" --validate plugin:PLUGIN_ID
astera runs checks --id RUN_ID --human

Add the Task before starting the Job, then use the resulting RUN_ID to read its checks. You can mix run configuration IDs and plugin IDs in one comma-separated --validate list. A missing, disabled, or unsuitable plugin is refused with PLUGIN_CAPABILITY_MISSING.

Astera keeps the first 20 findings of a plugin check and shows how many more there are when a total is available. Open the plugin's report link, when provided, for the full report. A passed check keeps its summary and link, with no findings. Plugin authors can return the first 20 as diagnostics and the full count as diagnosticsTotal.

When a check could not be made

A missing token, unavailable service, or stopped plugin is a check error, rather than a finding against the code. Astera retries it once immediately. If it still cannot run, the Task waits for your answer without spending a repair attempt. Open the question and choose:

In a shell, use astera questions answer --id QUESTION_ID --answer retry, or substitute one of the other two answers. A check-unavailable question accepts only those three values. MCP's get_completion and the SDK's completion.get carry the findings; plugin checks have no terminal output for get_check_output to read.

/astera-orchestration gives an Astera session a way to supervise multi-step work across Claude and Codex. The coordinator creates tasks, dispatches workers, waits for reports, and brings decisions back to you. The run stays visible in Jobs.

1. Open a new coordinator session in your project so the orchestration skill is loaded at startup. Astera provides it to every session it starts.
2. Describe the objective, which agent should do each part, the order, and how to check the result. Register usable accounts for the providers you request.
3. Open the project’s Jobs sidebar to follow the graph. Read questions and Gates when the coordinator needs a decision. Review the result before bringing changes into your project.

/astera-orchestration

Refactor the sign-in flow with Claude. After that, have Codex add regression tests. Run the project’s tests and request a cross-vendor review. If checks fail, repair and check again within three attempts. Ask me when a decision is needed.

The astera command brings sessions and Jobs to your terminal and scripts. With a compatible Host running, workers, worktrees, configured checks, reviews, and account rolling can continue while the app is closed. Reopen Astera to inspect the same work in its tabs and Jobs graph.

1. Set up your shell

1. Install Astera, add your accounts, and sign in. Install the Claude Code or Codex CLI you will use. Then open Settings → CLI → Command line tool (astera) and click Install the astera command.
2. On Windows, leave Add this folder to my user PATH checked to add %LOCALAPPDATA%\astera\bin automatically. On macOS and Linux, the command goes in ~/.local/bin; if needed, run the PATH line shown in the panel. Open a new terminal after installation. Sessions started by Astera already have the command.
3. Start the Host and check its capabilities. In host status, data.features includes spawn for workers, worktrees for isolated branches, dispatch for automatic Job execution and checks, and rolling for account switching.

astera version
astera host start
astera host status
astera accounts list --human

The examples below use placeholders. Replace ACCOUNT_ID with an ID from the account list and REPO_PATH with your project’s absolute path. Copy SESSION_ID, JOB_ID, and RUN_ID from data.id in their create or run results; each identifies a different object. After setup, you can close Astera and run these commands in your own shell.

2. Start an agent without opening a window

Choose an account, working folder, and prompt. Use sessions list to find existing sessions and sessions read to inspect one before sending a follow-up: terminal input goes to whatever is currently on its screen, including a prompt. For account rolling, add --roll-accounts with a comma-separated list of usable account IDs for the same provider.

astera sessions create --account ACCOUNT_ID --cwd "REPO_PATH" --kind terminal --prompt "Inspect the project and summarize its test setup."
astera sessions list --human
astera sessions read --id SESSION_ID --human
astera sessions send --id SESSION_ID --text "Run the existing tests and report the results."

astera sessions create --account ACCOUNT_ID --cwd "REPO_PATH" --kind chat --unattended hold --prompt "Inspect the project and summarize its test setup."
astera chats pending --session SESSION_ID --human

3. Run a Job and follow its checks

Use /astera-orchestration to have an agent plan the work. Once the Job is ready to run, find its ID and start a run from the shell. jobs run returns that run’s ID in data.id. If a run is already active, follow it instead of starting another.

astera jobs list --human
astera jobs run --id JOB_ID
astera runs follow --id RUN_ID --human
astera runs checks --id RUN_ID --human

The Host can dispatch tasks as dependencies clear, run configured validation and cross-provider reviews, and retry repairs within a Job’s convergence limit. runs follow streams progress; Ctrl+C stops watching without cancelling the work. Use runs stop --id RUN_ID to stop the run, or runs resume --id RUN_ID when it is ready to continue.

astera skills list --account ACCOUNT_ID --human
astera skills install --account ACCOUNT_ID --human

astera jobs create --objective "Improve the sign-in flow" --cwd "REPO_PATH"
astera tasks add --job JOB_ID --spec "Implement the sign-in changes and add regression tests" --account ACCOUNT_ID
astera jobs run --id JOB_ID

4. Handle decisions and automate the wait

When a Job needs a decision, inspect the open question and answer it from your shell. Replace QUESTION_ID with the question’s ID and the example answer with your decision. Start the Host again first if it has exited while waiting.

astera questions list --run RUN_ID --status open --human
astera questions get --id QUESTION_ID --human
astera host start
astera questions answer --id QUESTION_ID --answer "Use the existing authentication library."
astera runs wait --id RUN_ID --timeout-ms 3600000

Most commands return JSON by default; add --human for readable output or --quiet for IDs. runs follow emits newline-delimited JSON events by default. Use runs wait in scripts or on a configured local CI runner, and handle its exit code:

Other failures include 3 when the Host cannot be reached, 6 when the current state prevents the command, and 9 when the CLI and Host builds are incompatible. Read error.code, error.details, and error.nextSteps. Exit 7 from a command that changes work can mean its answer was lost; follow its request-status instructions before retrying.

To target a paired computer, put --runtime RUNTIME_ID before the command. Follow the Remote Runtime setup for pairing, permissions, and paths.

Use astera --help or command-specific help such as astera jobs --help. For all options, Chat approvals, scheduling, and troubleshooting, see the CLI reference.

Astera's MCP server lets a connected Claude Code, Codex, or Cursor client use the same local Host as the app and CLI. It can create a Job, start a Run, follow progress, inspect failed checks, and read How It Works records. A Job created over MCP appears in Astera and the CLI, and keeps running if the client disconnects.

Connect a client on this computer

1. Install the astera command in Settings → CLI, as in the CLI setup. MCP clients use that installed command to reach the Host; they do not need the app window open.
2. Under MCP access, choose Read only to let a client inspect work, or Read and control to let it create and run Jobs. The default is Read and control; Off refuses every tool.
3. Use the operating-system-specific line shown for Claude Code, Codex, or Cursor. The Claude Code and Codex rows also offer Register; Cursor uses the copied configuration. Registration for Claude Code and Codex goes to their default user configuration, so separately configured Astera accounts may need their own MCP entry.
4. Ask the connected agent to list Astera projects, then create and run a Job in a chosen project. create_job only saves the Job; run_job starts it. Use wait_for_run for progress and get_completion for Task checks.

astera mcp status

Run this in a shell to inspect MCP readiness without starting a Host. If no Host is running, a local MCP client starts one when it connects.

For a paired computer, pass runtimeId to a supported tool. The Remote Runtime guide explains the encrypted connection and how MCP settings combine with pairing permissions.

For client configuration, every tool, access rules, and HTTP troubleshooting, read the MCP reference.

Plugins are programs Astera starts and stops with its Host. They can send notifications to your own services, react to events, supply tickets for Jobs, or check completed work. Each runs in its own process using Astera's bundled Node; installing a plugin does not require a separate Node.js installation.

1. Open Settings → Plugins. Choose Install from a folder… for a prepared plugin folder, or Install by package name for a plugin published on npm.
2. Review its identity, version, capabilities, and requested permissions. Uncheck permissions you do not want to grant, then approve the installation.
3. Use the plugin's Configure button to enter required options and secrets. Saving restarts a running plugin. The list shows its state and why it cannot run; use Logs to investigate. A failed plugin needs Start again after its settings are corrected.
4. Use Disable to keep it installed without running it, or Remove to delete it together with its settings, secrets, and logs.

Event plugins resume from their saved position after a restart or time disabled, within the Host's event retention. Removing a plugin removes its saved position. Delivery can repeat an event, so an integration should deduplicate by event ID. Notifications more than an hour old when delivery reaches them are skipped and counted in the log.

astera plugins install --path "PLUGIN_PATH"
astera plugins list --human
astera plugins settings --id PLUGIN_ID
astera plugins logs --id PLUGIN_ID
astera plugins doctor --id PLUGIN_ID

Plugins do not keep an otherwise idle Host alive. Repeated crashes mark a plugin as failed; inspect its log before restarting it. For manifests, permissions, secret handling, packaging, and provider examples, read the plugin author guide.

Use the official TypeScript client, @astera-app/client, to build a script, CI step, bot, or dashboard. It reaches the same Host as the app, CLI, and MCP. Jobs created through it appear in Astera and keep running after your program exits.

Astera 1.5.0 includes @astera-app/client 0.5.0 with profile reads and profile selection for Jobs and Tasks, alongside source metadata, plugin check results, and GitHub lifecycle support. @astera-app/plugin-sdk 0.2.0 provides event, notification, job-source, and completion-check helpers.

1. Install Node.js 22 or later and Astera, and set up your agent accounts. In your integration project, install the client from npm. ESM, CommonJS, and TypeScript types are included.
2. Open Astera or run astera host start. The client connects to an existing Host; it does not start one itself. A script launched inside an Astera session inherits that session's profile.
3. Try a read-only call first. Save the example as list-jobs.mjs and run node list-jobs.mjs. Close the client when your script finishes.

npm install @astera-app/client

import { createAsteraClient } from '@astera-app/client'

const astera = await createAsteraClient()
try {
  const { items } = await astera.jobs.list({ status: 'running' })
  for (const job of items) console.log(job.id, job.objective)
} finally {
  astera.close()
}

A Job made from a ticket carries its origin in source. Task and completion events carry a plugin check's finding count as diagnosticsTotal, rather than the findings themselves. Read tasks.get or completion.get for the retained findings, and externalUrl for the full report when the plugin supplies one.

npm install @astera-app/plugin-sdk

To write a plugin, install @astera-app/plugin-sdk; it provides definePlugin and helpers for event, notification, job-source, and completion-check providers. See the SDK guide for connection errors, request IDs, cancellation, events, and runnable examples, and the plugin guide for providers.

The Runtime runs your agents and Jobs; the controller is the computer you use to manage them. Work stays on the Runtime when the controller sleeps, shuts down, or loses its connection.

1. Install Astera on both computers. On the Runtime, install and sign in to Claude Code or Codex, and register your project folders. Connect the computers over your LAN, VPN, or Tailscale.
2. On the Runtime, open Settings → Remote Runtimes → This computer. Choose its LAN or Tailscale address and click Turn on. The “this computer only” address cannot accept another computer.
3. Create a named pairing string. Read only allows inspection; Full control also allows starting and managing Jobs and sessions. Copy the string directly to your controller: it contains a secret, works once, and expires after 10 minutes.
4. On the controller, paste the string in Settings → Remote Runtimes and click Pair. In Jobs, select the Runtime and its project. In New session, choose where it runs, then open a running session or start one.

In Settings → Remote Runtimes → Details, see its Astera version, OS, profiles, policy, sandbox, extensions, credential names, and finding counts. Reports contain names, states, and counts only, never values, paths, commands, or Rule text. Only a person in the app or their own shell can read them; agents and MCP clients cannot.

Tick which local extensions you expect there. Comparison shows missing, different, off, secret missing, or same; differences and an older Astera become Findings. Reports are read when opening Runtime settings or Findings, at most once every five minutes, or immediately with Refresh. Offline views retain the last report and its time. Install or fix extensions on the Runtime itself; comparison never synchronizes them.

astera runtimes ping --id RUNTIME_ID
astera runtimes get --id RUNTIME_ID
astera ext list
astera runtimes expect --id RUNTIME_ID --add EXTENSION_ID

Run these in your own shell with IDs from the lists; expect --remove EXTENSION_ID clears an expectation. Agents cannot edit expectations. Runtime settings show each controller’s surface (app, CLI, MCP) and version. Agents meet the Runtime’s agent rules. The CLI and MCP let sandboxed sessions read work but refuse remote changes. These session checks can be bypassed by clearing the environment or using a pairing token directly; revoke a pairing to stop a controller you no longer trust. Update both computers: older Runtimes cannot report, and an older CLI counts as an agent.

astera runtimes add --pair -
astera runtimes list
astera --runtime RUNTIME_ID jobs list --human
astera --runtime RUNTIME_ID runs follow --id RUN_ID --human

Remote Runtime uses pinned TLS and a revocable token per controller, separately from MCP over plain HTTP. Use your private network; do not expose its port to the internet. Astera requires no relay subscription; your machine, network, and agent usage costs remain yours. See the Remote Runtime reference for shell setup, OS startup recipes, and troubleshooting.

Astera Host is a separate process on your computer that can own Terminal and Chat sessions, project terminals, and Run processes. When it owns a process, quitting the app leaves that process running. Reopening Astera reconnects to supported live sessions.

How It Works turns a finished piece of work into a readable explanation. Keep your original request beside an overview of the change, a flow diagram, the reasons behind decisions, and the files involved.

1. For your own sessions, enable Work unit tracking and choose an Explanation account in Settings → How It Works. The Host records finished Jobs Runs without this tracking setting.
2. Open a new session in a git project. Send /astera-task followed by a concrete objective, such as “Add Google sign-in and verify that signing out ends the session.”
3. Continue in that conversation. The skill tells the agent to record the start and finish of the task, even when the work takes several messages.
4. Open How It Works from the sidebar, or press Ctrl/Cmd + Shift + H. Select a completed record to read its explanation in a pane tab.

Some capabilities need a setting before use. Turn them on when they fit the way you work.

Closing an app in the agent workspace also ends the background programs it started. Windows tracks them in one process job; macOS and Linux can find detached children while their original parent is still running.

New Claude and Codex sessions receive a short introduction to the Astera features you have enabled. App and browser skills can be used when the agent needs to check the project, without you naming each skill. Codex accounts with their own developer_instructions keep those instructions; Astera does not replace them with its introduction.

Creative Hub keeps accounts for creative platforms whose CLIs your agents use. Higgsfield is the first supported platform. Its accounts and credits are separate from your Claude Code and Codex accounts.

1. Install the Higgsfield CLI, then open Settings → Creative Hub → Higgsfield. Import an existing login or add an account and sign in. If more than one workspace is available, select the one to use.
2. Choose Use this account. Higgsfield commands from Astera’s Terminal and Chat agent sessions use that current account. Add other accounts here when you need them.
3. When there are not enough credits to create a generation, the agent checks the other accounts and asks which to use. A switch requires your choice; Astera does not roll creative accounts automatically. Upload and job references can carry across as files after a switch.

astera higgsfield list
astera higgsfield use --account ACCOUNT_ID

Use the first command to inspect accounts and credits. After choosing, replace ACCOUNT_ID in the second with the Higgsfield account ID from that list. Platform subscriptions and generation credits are paid separately.

Version 1.5.0 also keeps Codex sessions attached to their own conversations, avoids ending a reused Windows process ID when closing a terminal, preserves linked config.toml files, and removes worktrees containing read-only files from sandboxed sessions. See the 1.5.0 release notes for the full list.

Useful shortcuts

Use Cmd on macOS and Ctrl on Windows or Linux. These are the defaults; you can remap them in Settings.

Explorer

Ctrl / Cmd + Shift + E

Jobs

Ctrl / Cmd + Shift + J

How It Works

Ctrl / Cmd + Shift + H

Markdown view

Ctrl / Cmd + Shift + V

Still need a hand? Ask on GitHub or explore the technical documentation.