# alineo prompt
URL: /docs/cli/commands/prompt

Send one prompt to a running agent sandbox and print the reply.



```bash
bunx alineo-cli prompt <sandbox-id> <message> [--spec <path>] [--json]
```

## Arguments [#arguments]

| Argument     | Description                                                        |
| ------------ | ------------------------------------------------------------------ |
| `sandbox-id` | The sandbox ID printed by `alineo start`/`alineo spawn`. Required. |
| `message`    | The prompt text to send. Required.                                 |

## Flags [#flags]

| Flag            | Description                                                                                                |
| --------------- | ---------------------------------------------------------------------------------------------------------- |
| `--spec <path>` | Skip the ledger lookup for the spec file — see [Why sandbox ID, not name](#why-sandbox-id-not-name) below. |
| `--json`        | Print `{ name, sandboxId, reply }` as JSON instead of the raw reply text.                                  |

## What it does [#what-it-does]

Calls [`Alineo.resume(sandboxId, { adapter, specPath })`](/docs/agent/api-reference/alineo#alineoresume), sends `message`, and prints the full reply once Pi finishes responding. `Alineo.resume()` restarts the sandbox's bridge process — Pi and the workspace are untouched, but any interactive stream a *different* process had open against that sandbox will be interrupted.

## Example [#example]

```bash
bunx alineo-cli prompt 4af65c3b-24a2-4fd1-999d-918faa9b97fd "What's in /tmp?"
```

## Why sandbox ID, not name [#why-sandbox-id-not-name]

Every other `alineo` command that looks up a session takes a sandbox ID, not a name. Names aren't unique — running `alineo start` twice on the same spec produces two sandboxes with the same name — and a name-based ledger lookup can hand back a sandbox that already died ungracefully (crashed before its `close()` ran, expired via OpenSandbox's own TTL) since nothing tells the ledger it stopped. `Alineo.resume()`'s own `connect()` call is the actual authoritative liveness check; addressing by sandbox ID means that's the *only* check, not a second opinion layered on an already-stale one.

`--spec <path>` skips `Alineo.resume()`'s own ledger lookup for the spec file entirely — needed when the sandbox's own `sandbox.created` event lives in a different ledger than this CLI invocation's own. This happens when prompting a child sandbox created via `alineo spawn` from inside another sandbox: the child's creation event is recorded in *that sandbox's own* internal ledger, not the one this CLI invocation reads from.

## Notes [#notes]

* `prompt` waits for the entire reply before printing anything — there's no streaming/incremental output on the CLI. For streaming, use `alineo`'s `agent.prompt()` directly.
* If the sandbox no longer exists (closed, expired, or never existed), `Alineo.resume()`'s `connect()` call fails and the command errors out rather than hanging.