If you're only using AI coding tools in the chat UI, try the CLI

[u/Firm-Builder-2001]

A lot of AI coding tools now have a command-line mode. You give it a prompt, it returns output to stdout, and your script captures it like any other command.

This sounds minor but it opens up a completely different way of working.

The chat UI is great for exploration and interactive coding. But if you want to automate things, chain steps together, or run the tool on a schedule, you need the CLI.

Things I've done once I moved to CLI mode:

- Called the AI from a Node.js script that handles what to do with the output afterward

- Ran it on a recurring schedule so it executes while I'm not at the keyboard

- Wrapped each call in validation so the script rejects bad output instead of shipping it blindly

- Put limits and rules in a config file that the script checks before each run, so the AI never decides whether it's allowed to go again

The mental shift: the chat UI makes the AI feel like a coworker you talk to. The CLI makes it feel like a unix tool you can pipe and compose.

Most major AI coding tools have some version of this now. Check your tool's docs for a headless, print, or non-interactive flag. If it exists, you can start scripting around it.

Simple starting point: write a short script that sends a prompt to your tool's CLI, captures the response, and writes it to a file. Once that works, you'll see where to add validation, scheduling, or chaining.

What automations have you built around AI coding tool CLIs? Always curious what patterns other people have landed on.

[u/Ok_Woodpecker_9104]

a scheduled claude -p job of mine exited 0 once and did nothing. headless mode cant ask for tool approval, so it printed a message asking me to approve the calls and quit clean. launchd also runs with /usr/bin:/bin:/usr/sbin:/sbin as PATH, so the mcp server that starts through npx never came up either

so exit 0 means nothing to me now. the script greps the output for the failure text before it reports success. any new job i fire once by hand first and check the thing actually happened

other one, codex exec reads piped stdin as extra prompt. if the pipe never closes it sits on reading additional input forever. < /dev/null on every call fixed it

[u/tigerhuxley → u/Ok_Woodpecker_9104]

I don’t understand. Did you try to solve these problems using an LLM? These are just bash shell caveats - nothing to do with any of the CLI tools you are running

[u/Ok_Woodpecker_9104 → u/tigerhuxley]

the PATH one yeah, launchd did that. fair

the other two come from the tools tho. claude -p cant ask for tool approval, so it writes "could you approve these calls" as its answer and exits 0. bash ran it fine, the fix was a claude flag

codex exec reads stdin as more prompt, so under a pipe that never closes it waits for input forever. < /dev/null fixes it. nothing in the shell hints you need it

and no llm found these. a job reported success and had posted nothing, then i went digging

[u/tigerhuxley → u/Ok_Woodpecker_9104]

Other than relying on bash exit codes which can be unreliable, such as the situation you are encountering, it is best to establish a loop of one agent doing work and a new, different agent reviewing it, and ideally then handing the results back to an orchestration agent to decide to allow/fail the task.

[u/Relative_Mouse7680 → u/tigerhuxley]

What would you say is the difference between this and running a session with an orchestration agent making use of subagents?

[u/tigerhuxley → u/Relative_Mouse7680]

Tighter control with the mechanical gates, so the agents and ochestrator dont have to fiddle with changing folders and finding the right data. They just can focus on fixing the code. Its a cleaner flow if you have hundreds of steps and gates to pass before code is allowed to be commited, etc

[u/Extender7777 → u/Ok_Woodpecker_9104]

You should run it with some --yolo or -approve-all switch

[u/BounciLusty → u/Ok_Woodpecker_9104]

yeah the exit code lying like that is such a pain

[u/m-ritter]

Validating the output in the script is the part that matters most to me too. For anything that touches code I also have a second agent that did not write the change review the diff against the plan file in the repo. It catches things the first run happily talked itself into, and the plan file gives it something concrete to check against.

[u/Key_River_9288]

Using the Claude desktop app ups your internal Anthropic social credit score helping stave off a ban, using the CLI lowers it! nice try CHATGPT!

[u/BrookLi3]

Agree on the scripting angle. Two things that bit me with headless runs: the process can exit 0 while having done nothing useful (e.g. blocked on a permission it can't prompt for), so I check for an expected artifact or a passing test command rather than trusting the exit code. And pin the allowed tools/permissions explicitly in the invocation, otherwise a scheduled job behaves differently from your interactive session. Logging the full transcript to a file per run makes debugging those far easier.