shelbi send

View as markdown
shelbi 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

ArgumentTypeDefaultDescription
<ID>string—Workspace name from the project's workspaces: block (required).
<MESSAGE>string—The message to type into the pane (required).

Flags

FlagTypeDefaultDescription
-p, --project <PROJECT>stringenv / cwd lookupProject 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.