dsh-plugin-cli-session

Usage

dsh --profile chat "explain this file"          # new session
dsh --profile chat -r "follow-up"               # resume the newest session here
dsh --profile chat -s  "follow-up"          # resume a specific session
dsh --profile chat -w ./scratch "start here"    # new session in another directory
dsh --profile chat -l                           # list this profile's sessions here
dsh --profile api -o json "summarize this"      # {"type":"result",…}
dsh --profile api -o stream-json "summarize"    # init line, then the result line

Flag	Meaning
-o, --output-format	Shape of what is printed; text is the conversational one
-n, --new	Start a new session (the default)
-r, --resume	Continue the newest session of this profile in this directory
-s, --session	Continue a named session
-w, --workdir	Create and enter a directory before starting a new session
-l, --list	List this profile's sessions here and exit
--json-schema	Ask the model for JSON in this shape (a prompt, not a constraint)

-o json / -o stream-json emit {type, subtype, is_error, duration_ms, num_turns, result, session_id, usage?}. stream-json prefixes a {type:"system",subtype:"init",…} line carrying the session id, cwd, provider, and model.

Misconfiguration fails at boot

The row's request comes from !!js ctx.cliStartup. Wire it wrong and the config schema's defaults quietly produce action: 'new' with an empty task — a session created and a model call spent on nothing. The runner refuses that at load instead, and says what to write:

cli-runner: no task to run. The row's config.request should be wired to the
startup service, as in `request: !!js ctx.cliStartup`.

A blank sessionTag (the label --list and --resume scope by) and a negative exitGraceMs are refused the same way.