DocsAutomation
View as Markdown

System-wide dev CLI

Drive Agentastic.dev from any terminal, cron, or CI runner

Overview#

For Slack, attach the plugin to an agent and run dev slack send --channel CHANNEL_ID "message" or dev slack reply --channel CHANNEL_ID --thread TIMESTAMP "message". --text-file PATH reads a multiline message. Use dev slack upload --channel CHANNEL_ID --file PATH [--thread TIMESTAMP] [comment] to attach an image or file from the agent's filesystem (maximum 50 MiB). Uploads require the bot's files:write scope; reinstall your Slack app after adding it. Optional --title and --alt-text describe the attachment. Slack commands execute the deployed plugin on the agent's own machine; they do not use the Mac socket. The portable form "$AGENTASTIC_SLACK_CLI" send … works in local, remote, and container launches and requires Node 18+. The server-managed dev slack shortcut requires helper 0.9.17+. MCP tools and the portable executable use the existing plugin deployment paths. Only the bot token is sent to the execution environment.

dev slack tasks [--channel CHANNEL_ID] and dev slack listener are separate Mac control commands for incoming Slack requests. They map to slack.tasks and slack.status on the Mac socket. The Mac does not expose slack.send or slack.reply RPC proxies. dev notify retains its app-notification meaning where supported. Task inventory includes a readable task name and, when Slack profile lookup succeeds, user_name, user_handle, and user_real_name. The internal task id and stable user_id remain available.

Agentastic.dev ships two CLIs, both invoked as dev:

  • Internal dev — auto-injected into terminal panes spawned inside Agentastic. Bound to the surrounding terminal/worktree via the AGENTASTIC_TERMINAL_ID and AGENTASTIC_SOCKET_PATH environment variables.
  • System-wide dev (this doc) — installed to a stable PATH location (e.g. /usr/local/bin/dev) so you can drive any running Agentastic.dev instance from a regular Terminal.app, an SSH session, a cron job, a CI runner, raycast, another editor, or a script — without depending on those environment variables.

Both CLIs talk JSON-RPC v2 over the same Unix-domain socket. The system-wide CLI adds an instance-discovery step on top.

Use the system-wide CLI when something outside Agentastic needs to launch an agent, check status, tail output, send instructions, focus a workspace, open a worktree, or trigger browser/task/repomix automation.

Installation#

Open Agentastic.dev → Agentastic → Command Line Integration… and follow the prompts. The installer copies a single Bash script to one of these locations (in preference order, picking the first whose parent directory exists):

  1. /usr/local/bin/dev
  2. /opt/homebrew/bin/dev
  3. ~/.local/bin/dev

Most commands require python3 to be available on your shell's PATH.

If /usr/local/bin is not user-writable, the installer prompts for your admin password and uses osascript to elevate. If a non-Agentastic file is already at the target path, it is moved aside to dev.backup (the installer recognizes its own shim by a magic header line).

Manual#

The script lives in the app bundle:

bash
cp "/Applications/Agentastic.dev.app/Contents/Resources/dev-system.bash" /usr/local/bin/dev chmod +x /usr/local/bin/dev

Uninstall#

Re-open the same menu item — if a previous install is detected, an Uninstall button appears.

Instance discovery#

Each running Agentastic.dev instance writes a small JSON record to:

code
~/Library/Application Support/Agentastic.dev/instances/<pid>.json

The record contains the pid, the IPC socket path, version, build, and bundle path. A primary.json file in the same directory points at the most recently focused instance and is used as a tiebreak hint.

Resolution rules:

  1. If --instance <pid> is given, that instance is used (or an error if it isn't responding to ping).
  2. Else, if AGENTASTIC_SOCKET_PATH is set and responding, that socket is used. This keeps calls made from Agentastic terminals pinned to their owning app instance.
  3. Else, if exactly one instance is responding, it is used.
  4. Else, if primary.json points at one of the responding instances, it is used.
  5. Otherwise the CLI exits with an error and tells you to pass --instance.

You can always inspect the registry with:

bash
dev instances

Command reference#

All commands accept the global flags: --instance <pid>, --json, -q/--quiet, --cwd <dir>.

Discovery#

CommandPurpose
dev instancesList running Agentastic.dev instances (does not need an instance)
dev pingShow info about the resolved instance (instance.info RPC)
dev capabilitiesList supported JSON-RPC methods

Workspaces & repos#

CommandPurpose
dev workspaces (dev ws)List open workspaces
dev focus <workspace_id>Bring a workspace window to the front
dev import <path>Open a folder as a new workspace
dev reposList repositories across workspaces

Worktrees#

These are the canonical worktree verbs used both system-wide and inside Agentastic terminals. The default target is the active repository of the resolved instance.

CommandPurpose
dev list (dev ls)List worktrees with branch, agent icon, diff stats, PR state
dev create <branch> [from_branch]Create a new worktree
dev rename <display_name>Compatibility alias for dev agent rename using the current terminal/worktree/cwd
dev rename --clearCompatibility alias for dev agent rename --clear
dev remove <path> [force]Remove a worktree
dev open <path>Activate a worktree in its window
dev status <path>Full status payload for a worktree

dev rename is a backward-compatible alias for the canonical dev agent rename command. Inside an Agentastic terminal it targets that terminal's agent. From another shell, run it inside the agent worktree or provide a working-directory hint explicitly:

bash
dev --cwd /path/to/worktree rename "Checkout polish"

Like dev agent rename, the alias changes only the persisted agent display_name; it does not rename the worktree directory or branch. The main worktree has no agent identity and cannot be renamed this way.

Agents & terminals#

CommandPurpose
dev agentsList native chats and terminals, including surface and status
dev agent create [flags]Create an editor agent in a new or existing worktree
dev agent task <prompt> [flags]Start an editor agent or continue a session (submit is an alias)
dev agent rename [flags] <display-name>Set an existing agent's display-only name
dev agent rename [flags] --clearClear a custom display name
dev agent listAlias for dev agents
dev send <terminal_id> <text>Type into a terminal and append to <worktree>/.agentastic/inbox/<id>.md
dev tail <terminal_id> [N]Print the last N (default 50) lines from a terminal's scrollback
dev terminals (dev terms)List all terminals across workspaces
dev newtab [command]Create a terminal in the caller's worktree; preserves focus
dev remote sessions [--repo <path>] [--orphans]List Remote SSH server sessions
dev remote kill <session_id> [--repo <path>]Kill one Remote SSH server session
dev remote sessions close --orphans [--repo <path>]Kill Remote SSH sessions no longer referenced by local app state

Launching and monitoring workers#

New agents open in the main editor. Use --surface sidebar or --surface utility for a panel. --focus controls selection independently: a background launch still creates a saved tab that appears when you select its worktree. --interface chat|terminal selects the presentation; the provider's configured interface is used when omitted.

dev help agent prints a complete workflow. dev help agent create and dev help agent task work without a running app. The in-app agent helper uses the same parser and help as the system CLI. The updated client checks agent API compatibility before launching; an older running app is rejected instead of silently ignoring placement flags. Rebuild/update and relaunch the app to use these commands. Existing managed CLI installations refresh from bundled content at app launch, including builds with the same version number.

CommandPurpose
dev agent createCreate a worker in a new worktree, or use --worktree <path> for an existing one
dev agent taskStart in an existing worktree, or continue --session <uuid>
dev agentsList native chats, terminals and queued submissions with surface and runtime status
dev agent status --session <uuid>Inspect one agent, including native chats without a terminal
dev agent tail --session <uuid> --lines 80Read native conversation entries or terminal output
dev agent reveal --session <uuid> --focusSelect an existing agent
dev agent move --session <uuid> --surface editorMove a panel conversation into the editor without restarting it
dev agent interrupt --session <uuid> --clear-queueInterrupt a native chat and discard its pending messages
dev agent queue --session <uuid>Inspect messages; use --clear for all or --delete <message_id> for one
dev agent steer --session <uuid> --prompt <text>Steer a running native chat that supports injection
dev agent launch-status --request-id <uuid>Inspect a durable creation receipt after a timeout

A native chat has a session_id and no terminal_id. Use session-based commands for orchestration. Terminal-only commands dev tail, dev send, and dev terminals remain available for terminal interactions.

dev agent create flags#

code
--prompt <text> Initial task (choose this or --prompt-file) --prompt-file <path> Read a UTF-8 task file --repo <path> Open repository; defaults to the caller's repository --agent <id> Agent command or definition; defaults to the repository selection --name <name> Worktree name; defaults to a generated city name --branch <name> Alias for --name --from <revision> Local branch or commit; defaults to the configured base branch --from-origin Fetch the selected branch from origin explicitly --from-local Use the local revision (default, independent of the UI origin toggle) --worktree <path> Existing worktree; cannot combine with name/from/mode --surface <area> editor (default) | sidebar | utility --interface <kind> chat | terminal; default is the provider's configured interface --model <id> Model option --thinking <id> Thinking-level option --label <name> Apply a worktree label --mode <mode> worktree (default for Git) | local | container --run-mode <mode> agent (default) | agentAutoApprove | plan --request-id <uuid> Stable creation identity; reuse for retries with identical options --timeout <seconds> Client wait for startup, 1..3600; default 120 --focus Reveal the resulting agent; default preserves current selection

Creation uses an already-running app and its existing workspace window. Outside Agentastic, select an instance using dev --instance <pid> … when several are running. An exact commit base currently requires a local repository and --from-local.

New workers default to interactive permissions. agentAutoApprove uses the provider's unattended mode; for Codex this disables its sandbox and command approvals. Use it for work authorized to run unattended. Login and task questions may remain. Children do not inherit the coordinator's approval policy.

Example: launch, inspect, and continue a worker from the coordinator's repository:

bash
request_id=$(uuidgen) dev --json agent create --request-id "$request_id" --agent codex \ --name fix-tests --from main --prompt-file task.md > launch.json # Continue only if create succeeds and launch.json contains a launch receipt. session_id=$(python3 -c 'import json; print(json.load(open("launch.json"))["session_id"])') worktree_path=$(python3 -c 'import json; print(json.load(open("launch.json"))["worktree_path"])') dev agent status --session "$session_id" dev agent tail --session "$session_id" --lines 80 dev agent reveal --session "$session_id" --focus dev agent task --session "$session_id" --worktree "$worktree_path" \ --prompt "Run the focused test again"

The launch receipt includes session_id, surface, interface, worktree_path, request_id, and launches for every created worker. terminal_id is included only for a terminal. Launch success does not mean the task is complete.

Launch-status records the last preparation/startup phase and known target IDs. If creation times out, inspect dev agent launch-status --request-id "$request_id". Retrying with the same ID and options returns the same outcome; it does not start another worker. Conflicting options are rejected. If the app restarted during startup, the receipt reports unknown; inspect existing agents before starting any replacement. --timeout limits the client wait, not the worker's task duration.

dev agent task flags#

This command uses an existing worktree. Omit --session for a new editor agent; pass a known UUID to continue that conversation on its existing surface. A new supplied UUID reserves a new session, so do not invent a new UUID for a continuation.

code
--session <uuid> Existing session, or an explicitly reserved new UUID --worktree <path> Target an open worktree --cwd <path> Resolve the owning workspace --surface <area> editor (new-session default) | sidebar | utility --interface <kind> chat | terminal (new sessions only) --agent <id> Provider/definition (new sessions only) --provider <id> Alias for --agent --model <id> Model (new sessions only) --thinking <id> Thinking level (new sessions only) --run-mode <mode> agent | agentAutoApprove | plan (new sessions only) --prompt <text> Task text; a positional prompt also works --prompt-file <path> Read a UTF-8 task file --focus Reveal the result

accepted and created acknowledge queue admission, not provider startup. Check dev agent status and dev agent tail for failures and approval requests. A prompt saying “stop” is an ordinary queued message. Interrupt and clear old instructions explicitly before sending a corrected continuation:

bash
dev agent task --worktree /path/to/repo-worktrees/fix-tests \ --surface utility --agent codex --prompt-file review.md dev agent interrupt --session "$session_id" --clear-queue dev agent queue --session "$session_id" dev agent task --session "$session_id" --worktree "$worktree_path" \ --prompt "Continue with the corrected scope"

interrupt without --clear-queue also supports terminals, using Ctrl-C. Native chat queues can be inspected and cleared; a terminal provider's private prompt queue is not exposed by this API.

JSON-RPC#

agent.create accepts the corresponding parameters repo, agent, name, from_branch, from_origin, target_worktree_path, surface, interface, model, thinking, label, mode, run_mode, prompt, request_id, and focus. The parameter request_id is the durable retry key. The envelope's id only correlates the response and does not deduplicate launches. Files are read by the CLI and transmitted as prompt text; the timeout is managed by the client.

agent.task.submit accepts session_id, worktree_path, cwd, surface, interface, provider/model/thinking/run-mode options, prompt, and focus. agent.session.control accepts session_id and an action of status, tail, interrupt, steer, queue, reveal, or move; optional parameters include lines, clear_queue, clear, delete_id, prompt, surface, and focus. agent.launch.status accepts a request_id.

Read one newline-terminated response, verify the envelope id, and check ok before consuming the result. A launch failure may leave a worktree or failed session to inspect.

dev agent rename#

Rename the current agent from one of its Agentastic terminals, or target an existing agent by worktree path or terminal ID:

bash
dev agent rename "Payments cleanup" dev agent rename --worktree /path/to/worktree "API migration" dev agent rename --terminal <terminal_id> "Reviewer" dev agent rename --workspace <workspace_id> --worktree /path/to/worktree "API migration" dev agent rename --clear

--worktree and --terminal are mutually exclusive. With neither flag, the CLI resolves the caller's terminal/worktree context and then tries the current working directory. An explicit --worktree or --terminal takes precedence over the calling terminal's workspace, so it can target an agent in another open workspace. If the selector is ambiguous across open workspace windows, add --workspace <workspace_id> to constrain it. --workspace is valid only with an explicit selector. The main worktree cannot be renamed as an agent.

This command changes only the persisted display_name shown in Agentastic. The technical name, Git branch, worktree directory, terminal identity, and running agent process are unchanged. --clear restores the worktree directory name as the display name. The value is persisted immediately; a visible sidebar row reveals the new name through a one-second Braille animation.

The legacy dev rename spelling invokes this same command and writes the same canonical display-name setting.

For a Remote SSH agent, run the same command inside a newly created Agentastic remote terminal. Remote server v0.8.13 and later put a server-managed dev on that terminal's PATH and relay the request to the Mac workspace that owns the PTY. The daemon copies its exact running executable to a versioned path such as ~/.agentastic/bin/dev-0.8.15, then points ~/.agentastic/bin/dev at that immutable copy. When the name is unused and no full desktop CLI is installed, it also links ~/.local/bin/dev to the private entry point so common Linux login profiles continue to select it. On macOS, remote server v0.9.11 and later remove their own user-level link when a full desktop CLI is detected, preventing the rename-only helper from shadowing commands such as dev ping. The daemon never replaces an existing user shim or full desktop CLI.

Remote server v0.8.14 also accepts the top-level dev rename compatibility alias. On v0.8.13, use the canonical dev agent rename spelling.

Remote server v0.8.15 waits for the owning Mac app to validate and persist the rename before it reports success. App-side validation or settings-save failures are returned directly by the CLI, and a missing app response fails after a bounded timeout instead of reporting a rename that may not have happened.

If the remote daemon predates v0.8.13, connect with a current app. An idle daemon upgrades automatically. If it still owns terminal sessions, use Remote Sessions -> Restart Server; this intentionally ends those sessions. Open a new remote terminal afterward so it receives the managed CLI environment. You can verify the selected command with command -v dev and dev --version. If a pre-existing user shim still wins, call ~/.agentastic/bin/dev explicitly. Quit older Agentastic.dev builds connected to the same host while upgrading: different app versions share the remote install path, so an older client can otherwise redeploy its bundled server after the restart.

As a no-restart fallback, run the current CLI on the Mac, find the remote terminal with dev agents, and target its ID explicitly:

bash
dev agent rename --terminal <remote_terminal_id> "Reviewer"

Restarting the daemon never updates a separately installed global dev. From an ordinary SSH shell, the daemon-managed command is available explicitly as ~/.agentastic/bin/dev; pass --terminal <remote_terminal_id> because that shell has no implicit Agentastic terminal context.

Remote SSH sessions#

bash
dev remote sessions dev remote sessions --orphans dev remote kill <session_id> dev remote sessions close --orphans

The session list is queried from the remote agentastic-dev-server. A session is marked orphaned when its remote working directory is under the selected repo but Agentastic has no editor tab, utility terminal, or persisted terminal reference for it.

Checking and messaging agents#

The system-wide CLI is designed for status dashboards, bot integrations, and scripts. Use --json when another program will consume the result:

bash
dev --json agents \ | jq '.agents[] | {display_name, terminal_id, worktree_path, waiting_for_input, last_command}' dev --json list \ | jq '.worktrees[] | {display_name, branch, path, additions, deletions, pr_number}'

Tail a running agent terminal:

bash
dev tail <terminal_id> 80

Send instructions to a running agent:

bash
dev send <terminal_id> "Run the focused test again and summarize the failure."

dev send types into the terminal and appends the message to:

text
<worktree>/.agentastic/inbox/<terminal_id>.md

That gives the terminal session and file-based tooling a shared message trail.

Notifications, tasks, browser, repomix#

These forward to Agentastic JSON-RPC methods:

CommandPurpose
dev notify [--title <title>] [--subtitle <subtitle>] [--body <body>] or dev notify <title> [body]Add a durable, terminal-routed inbox notification
dev notify --clearResolve the current terminal notification while retaining read history
dev task <subcommand> ...Forward to the scheduled task service
dev browser <subcommand> ...Forward to browser automation
dev repomix [...]Pack the active workspace via repomix

See Task CLI Reference and Browser CLI Reference for the full in-app subcommand surface. When dev browser is invoked from inside Agentastic and the injected dev-browser helper is available, the system-wide CLI delegates to it so the full browser command syntax is preserved. Requests include the calling terminal, workspace, and current working directory when those values are available, so browser tabs stay associated with the agent's worktree instead of whichever worktree is currently visible. Outside Agentastic, advanced forwarded parameters are passed as key=value pairs:

bash
dev task run task_id=<task-id> dev browser navigate url=http://localhost:3000 dev repomix style=markdown max_tokens=128000

JSON output mode#

By default, list-style commands print a column-aligned table. Pass --json for the raw JSON-RPC result payload, suitable for jq and scripting:

bash
dev --json workspaces | jq '.workspaces[] | select(.focused) | .id' dev --json list | jq '.worktrees[] | {name, display_name, branch, additions, deletions}'

Exit codes:

CodeMeaning
0Success
1RPC error returned by the app
2Bad command-line usage
4No live instance / multiple instances and no --instance flag

Recipes#

Cron: nightly snapshot worktree#

bash
0 3 * * * /usr/local/bin/dev create "nightly-$(date +\%Y\%m\%d)"

Raycast: focus a worktree by branch name#

bash
#!/usr/bin/env bash branch="$1" id="$(dev --json list | jq -r --arg b "$branch" '.worktrees[] | select(.branch==$b) | .path')" [[ -n "$id" ]] && dev open "$id"

CI runner: import a freshly cloned repo and kick off a task#

bash
git clone "$REPO" "$WORKDIR" dev import "$WORKDIR" dev task run "$TASK_ID"

Broadcast a message to every running agent#

bash
dev --json agents \ | jq -r '.agents[].terminal_id' \ | while read -r id; do dev send "$id" "Heads up: deploy in 5 minutes"; done

OpenClaw or phone bot: check agent status#

Run a trusted bridge on your Mac, then let OpenClaw, a web dashboard, or a Telegram bot call an allowlisted set of dev commands:

bash
case "$COMMAND" in agents) dev --json agents ;; worktrees) dev --json list ;; tail) dev tail "$TERMINAL_ID" 80 ;; send) dev send "$TERMINAL_ID" "$MESSAGE" ;; esac

The recommended shape is:

text
phone / bot / web UI / OpenClaw -> authenticated local bridge -> /usr/local/bin/dev -> Agentastic JSON-RPC socket

Do not expose the raw socket or an arbitrary shell endpoint directly to the internet. Keep a small allowlist of supported actions and authenticate the remote caller.

Differences vs the internal dev#

Internal dev (in-app terminal)System-wide dev (this CLI)
DiscoveryImplicit via env varsRegistry directory + --instance
Default targetThe owning terminal/worktreeThe single live instance, or --instance
RoutingTerminal-local commands plus JSON-RPC for app operationsAlways over the discoverable socket
InstallationAuto-injected by the appMenu item or manual copy
Command surfaceIncludes terminal-local verbs (dev split, dev resume, dev cd)Cross-instance verbs (dev instances, dev workspaces, dev focus, dev import, dev tail)

See Internal dev CLI for the in-app terminal command surface, including terminal splits, notifications, worktree RPCs, browser automation, task scheduling, and repomix.

Troubleshooting#

  • error: no running Agentastic.dev instances found — open the app, then retry. If the app is open but the message persists, the IPC socket may have failed to start; check Console.app for AgentasticSocketManager logs.
  • error: multiple Agentastic.dev instances running; pass --instance <pid> — run dev instances to see them and pick one.
  • Stale registry entries — entries are removed on app quit. If a crash leaves one behind, the CLI ignores it because ping fails.
  • Sandboxed Debug builds — when running a sandboxed Debug build of the app, file-system writes from dev import may be denied. Use the official release or ./build.sh (Developer ID, non-sandboxed) for full functionality.

Terminal targets and background creation#

Terminal commands default to the originating terminal's workspace and worktree, including when another worktree is selected in the app. Agent processes without a terminal use their injected worktree context. External shells resolve an open worktree from their current directory or the global --cwd option. Ambiguous or stale targets produce an error instead of using the focused window.

bash
dev newtab dev split --vertical dev hsplit --command 'npm test' dev --json list # Includes worktree_id dev newtab --worktree <worktree_id> --command 'npm test' dev vsplit --worktree-path /path/to/worktree dev newtab --worktree <worktree_id> --focus

--worktree accepts the worktree_id returned by dev list. IDs are scoped to an open workspace and remain stable when its saved layout is unloaded; query them again after reopening the workspace. --worktree-path accepts an absolute path or a full remote URI. Add --workspace <workspace_id> to disambiguate an explicit target. Explicit worktree and session targets override the caller's inherited context; conflicting selectors are rejected.

Creation starts the shell and optional command immediately, without switching worktrees or taking keyboard focus. Use --focus to reveal the result. Remote and cloud targets create a fresh PTY on the target host; an existing agent's PTY is not reused. The remote server must support terminal/control, and its owning app must be connected.

dev, the it2 compatibility shim, and the server-managed remote CLI share the same app-side routing and creation service. The orchestration interface remains available:

bash
it2 session split output --vertical --session <source_id> # Created new pane: <child_id> it2 session run --session <child_id> 'npm test' it2 session close --session <child_id>

The split response identifies the terminal the app actually created. Run, close, resume, and explicit focus commands address sessions in inactive worktrees too. A session split is removed when its child exits, including while its worktree is in the background.

Focus is opt-in#

CLI operations preserve the user's current workspace, selected tabs, and keyboard focus by default. This applies to terminal creation and splits, agent creation/submission, browser automation, and editor output. Background browser popups remain in their originating worktree instead of opening a foreground window.

Use --focus to permit presentation changes for the current command:

bash
dev newtab --command 'npm test' --focus dev session focus --session <terminal_id> --focus dev focus <workspace_id> --focus dev open /path/to/worktree --focus dev agent task --focus 'Investigate the failure' dev --focus agent create --prompt 'Investigate the failure' dev browser open https://example.com --focus

The system CLI also accepts --focus before the command; the internal browser helper accepts it before the browser verb. Equivalent it2 and remote terminal commands carry the same permission.

Commands explicitly named focus, including browser element/webview/tab focus, require --focus. Importing a workspace or opening a worktree without the flag prepares it in the background. An existing workspace owned by another app instance is reported without opening a window there.

Closing a selected terminal/browser or deleting the active worktree without --focus returns an error. Select another view first, or pass --focus to authorize the visible change. Closing background targets preserves the current selection. Completed visible split panes retain their output until dismissed; inactive-worktree panes can still be cleaned up automatically.

dev repomix --editor (internal) and dev repomix editor=true (system-wide) add output to the originating worktree without selecting it. Agent and scheduled launches no longer bring up Agent Home as a side effect. Scheduled runs remain background operations; focus permission is not stored for future scheduled executions.

Browser commands preserve focus even through delayed WebKit callbacks. DOM focus/blur/select requests and script-driven window focus are suppressed during background automation; explicit --focus and native user interactions enable them. Notifications still post normally and only reveal their target when the user activates the notification.