alineo prompt

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

Arguments

Flags

What it does

Calls Alineo.resume(sandboxId, { adapter, specPath }), 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

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

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

• 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.