BlogContact

How I Turn Claude Code Into a Scriptable Workflow With dash-p

I do not want a second AI stack just to automate a local coding job. If I already have Claude Code open in the terminal, I want to script that session, not rebuild my process around a different protocol.
That is the niche dash-p fills. It launches the official claude command, drives the real interactive TUI, and gives me both a CLI and a query() API. I use it when I want Claude Code to stay the source of truth, but I still want to call it from a shell script, a repo utility, or a small TypeScript tool.
Anthropic's own support docs changed the context here. Starting June 15, 2026, subscription plans can claim a separate monthly Agent SDK credit for Agent SDK usage and claude -p, while interactive Claude Code in the terminal or IDE stays on the normal usage limits. That does not make dash-p an escape hatch; it makes the choice clearer. If you want a local automation bridge around the real TUI, dash-p is in that lane. If you want the official programmatic path, Anthropic's Agent SDK credit support article and Claude API pricing are worth reading side by side.

What dash-p actually does

The product is simple on paper, which is why I like it.
  • It launches the official claude process.
  • It injects prompts and keystrokes into the live TUI.
  • It reads the rendered terminal output back out.
  • It surfaces the result through a CLI and a TypeScript query() API.
  • It keeps the same session, login state, and permissions model that Claude Code already has.
That means I can use it for the boring jobs: repo summaries, quick transforms, one-off local automations, and small scripts where I want the model to stay inside my own terminal session.
npm install -g @ybouane/dash-p

dash-p "summarize this repo"
If I do not want a global install, I can still run it with npx:
npx @ybouane/dash-p "what color is the sky"
The SDK side is the same idea in a TypeScript shape:
import { query } from "@ybouane/dash-p";



for await (const msg of query({

  prompt: "In one sentence, what is a pseudo-terminal?",

  options: { model: "sonnet", includePartialMessages: true },

})) {

  if (msg.type === "result") console.log(msg.result);

}
I would not use this as a hidden production backend. The whole point is that it uses the real interface, which makes it practical and also means UI changes can break it. For a personal workflow tool, that tradeoff is acceptable.

Where I would use it

The strongest use case is local scripting around a session I already trust.
  • summarize a repository before a review
  • generate a quick explanation from the current workspace
  • wrap a prompt in a shell pipeline
  • call Claude Code from a small TypeScript helper
  • automate repetitive local tasks without moving to a separate API stack
I also like it because it fits a broader workflow pattern I keep using elsewhere: keep one source of truth, then add thin automation around it. I've written about that in keeping a draft-first blog workflow stable, making a video workflow portable across browser, server, and React, keeping video templates stable as data changes, and turning product data into reusable video demos without forking templates. dash-p belongs to the same family of tools: keep the real thing intact, then automate around it instead of replacing it.

The tradeoff is the point

If you are looking for a polished abstraction, this is probably not it.
If you want:
  • the official Claude Code account and session you already use
  • a scriptable local bridge
  • a CLI for quick jobs
  • a query() API for TypeScript
then dash-p makes sense.
If you want:
  • the vendor-supported non-interactive path
  • a first-class SDK for app code
  • an automation layer that is insulated from terminal UI changes
then the official Agent SDK or claude -p path is the better fit.
For me, the decision comes down to control. I use dash-p when I want the session to stay local and interactive, but I still need to drive it from code. That is a useful middle layer for internal tooling, experiments, and personal productivity.
If you want to try it, start with the GitHub repo and run one prompt from your shell. Then decide whether the TUI is the right interface to automate, or whether you should stay with a direct SDK.

Final note

dash-p is not magic. It is a practical bridge between a terminal workflow and code. That is exactly why it is useful.