shelbi send
View as markdownshelbi send [OPTIONS] <ID> <MESSAGE>shelbi send injects a follow-up message into a running
workspace. The text is delivered into the
workspace's live session, exactly as if you'd typed it there
yourself. Use it to nudge, correct, or add a note to an agent that's already
working, without interrupting or restarting the session.
Shelbi delivers the text first, sends Enter as a separate key event, and then
waits for evidence that the session accepted the submission. If the text remains
in the input box, Shelbi retries Enter once. A busy Claude session may keep the
accepted text visible as queued input until its current turn ends. Every result
is recorded in ~/.shelbi/events.log as status=submitted, status=queued,
or status=stuck; a stuck result also makes the command fail instead of
silently waiting for a human keypress. A transport failure is also recorded as
status=stuck. Claude and Codex sessions are both verified this way, each with
its own parser. A custom runner still receives the split text/Enter sequence,
but Shelbi has no parser for its screen, so the result is status=unverified
(printed as sent (unverified)): delivered, with no runner-specific proof.
Which parser applies follows the project's baseline runner
(orchestrator.runner).
On success send prints ✓ sent, ✓ queued, or ✓ sent (unverified), with
the workspace and session it reached. Sends to the same workspace are
serialized with dispatch and resume, so two messages never merge into one
prompt.
ID must name a workspace declared in the project YAML's workspaces: block.
An unknown name errors and lists the declared workspaces. The workspace must
also have a live session: send never starts one, so an idle workspace is an
error. Open it with shelbi open or dispatch an issue to it
first.
Because send writes input into a live session, the message content is
ephemeral. Shelbi records and verifies the delivery result, but the worker
does not semantically acknowledge or persist the message body. When you need a
message that survives, is logged, and is acked by the workspace, reach for
shelbi message instead. See the comparison there.
Arguments
| Argument | Type | Default | Description |
|---|---|---|---|
<ID> | string | — | Workspace name from the project's workspaces: block (required). |
<MESSAGE> | string | — | The message to type into the pane (required). |
Flags
| Flag | Type | Default | Description |
|---|---|---|---|
-p, --project <PROJECT> | string | env / cwd lookup | Project to operate on. Defaults to $SHELBI_PROJECT, or the registered project whose work_dir contains the current directory. |
Examples
Nudge the alpha workspace with a follow-up instruction:
shelbi send alpha "also update the changelog before you commit"See also
shelbi message— the durable, acked counterpart: appends a JSON record to a task's message log instead of typing into a pane.- Workspaces — what a workspace is and how the
workspaces:block names them.