Simon Willison published a write-up on Claude Code’s remote control features back in late February that I keep returning to. The short version: you can drive Claude Code from outside the interactive session, passing prompts via flags and piping output like you would with any other CLI tool.
This might sound minor, but it reframes what Claude Code is. It’s no longer just a REPL you sit in front of; it becomes a composable piece of a larger pipeline.
The Mechanics
The core of it is Claude Code’s non-interactive mode. You can invoke it with a prompt directly:
claude -p "refactor this function to use async/await" src/handler.jsCombined with the --output-format flag for structured output, you can pipe this into other tools, collect results in scripts, or wire it into CI. Willison’s post explores several patterns along these lines, including feeding Claude Code’s output back into itself for multi-step transformations.
What makes this interesting is that the model isn’t just answering a question; it has full access to the file system, can run tests, and can iterate. You’re not scripting a chatbot. You’re orchestrating an agent that can actually change things.
Why This Matters for Automation
I build Discord bots, so my mind immediately goes to workflow automation. The pattern here is genuinely useful: instead of writing a bunch of scaffolding code by hand, you could have a script that detects a new feature branch, runs Claude Code against the relevant files with a targeted prompt, and opens a draft PR with the result. That’s not a toy demo; that’s a real reduction in repetitive work.
The same applies in systems contexts. If you’re maintaining a codebase with consistent patterns (say, adding a new route handler, or writing a new Rust module that follows a particular structure), a wrapper script around Claude Code in non-interactive mode can handle the boilerplate while you stay focused on the logic that actually varies.
The Tradeoffs
Automating an agent that modifies your file system does require some care. The surface area for unintended changes is larger than running a formatter or a linter. Good scripting here means being specific with prompts, scoping what files Claude Code can touch, and probably running in a branch with a review step before merging.
Willison’s framing throughout is measured: this is a powerful primitive, but it works best when you treat it as a tool with a well-defined job rather than a general-purpose autonomous system you’ve let loose on a repo.
What I’m Taking From This
The mental model shift is the important part. Claude Code in non-interactive mode fits naturally into the Unix philosophy: do one thing, accept input, produce output, compose with other tools. That framing makes it much easier to reason about where it belongs in a workflow and where it doesn’t.
For anyone building bots or automation pipelines, this is worth experimenting with. The combination of file access, tool use, and scriptable invocation is genuinely different from what earlier AI coding tools offered.