No API Key,
Just AI Features.
Call the claude CLI already installed on your machine, straight from server code. No signup, no billing, no SDK.
WHY THIS WORKS
While building a personal local tool — a “port manager” app — I wanted to add an AI feature that suggests project names. The first roadblock hit immediately: getting an API key, registering a payment method, and tracking usage felt like way too much overhead for a side project.
Then I realized: if Claude Code is already installed on your machine, you can call Claude straight from a local server (Node.js, Bun, PHP — anything) without a separate API key. The port manager’s AI name-suggestion feature runs on exactly this pattern today. This post breaks down the mechanism so anyone can apply it to their own project.
parse the output.
What a human should understand
Why this works, and when to use it (or not) — the judgment calls before you write any code
The core ideaclaude is just a command-line program
to issue
authenticated CLI session
implement
→ parse, that’s it
timeout
hung subprocess
required
installed CLI
Installing Claude Code gives you a claude executable in your terminal. It’s the same tool you chat with every day — but it’s also just a regular CLI program, which means any other program can launch it too.
Add the -p (or --print) flag and Claude skips the interactive session entirely: take one prompt → print the answer to stdout → exit. From your server code’s point of view, that’s nothing more than “run an external program, read back some text.”
This isn’t unique to Claude Code. Codex CLI works on the same principle once it’s installed locally and logged in. Instead of an interactive session, its exec subcommand (alias e) plays the same role as -p — “one prompt in → one final answer → exit.”
My first attempt just used which claude to find the path. Worked fine in a terminal. But once I launched the port manager as a GUI app, that function kept returning null. GUI apps usually start in a non-login shell that never reads .zshrc, so the PATH entry for a claude installed via nvm/homebrew was simply empty. Only after wrapping the lookup in a login shell (zsh -l -c) did it reproduce the same PATH you get in a normal terminal — that’s exactly why Part B’s resolveClaudePath() bothers with zsh -l -c. codex hits the identical problem when launched from a GUI app, so it needs the same path-resolution trick.
When to use itPros, caveats, and the call to make before you write code
| Criterion | Official Anthropic API | Local claude CLI call (this post’s approach) |
|---|---|---|
| Setup | Requires an API key + billing method | None — reuses your already-authenticated CLI session |
| Cost | Billed separately by token usage | Covered by your Claude Code subscription, no extra charge |
| Deployment target | A service deployed to the web for many users | A personal local tool that only runs on your own machine |
WHEN TO USE
No API key management — reuses the already-installed, already-authenticated claude CLI session as-is.
No extra cost (for personal use) — covered by your Claude Code subscription/usage, with no separate server-side API billing.
A great fit for local-only tools — not a deployed multi-user web service, but a personal tool (like a port manager) that only runs on your own machine.
WHEN NOT TO
Not a fit for a production service with multiple users. This is fundamentally “my local server calls the CLI installed on my machine” — if you’re deploying to the web for the general public, the official Anthropic API + a real API key is the right choice.
Fails outright without the CLI. If resolveClaudePath() returns null (Claude Code isn’t installed, etc.), that feature should degrade to a 503 error.
Always set a timeout. A subprocess call may never respond, so you need a kill switch (proc.kill()) to force it to terminate.
What to hand straight to an AI
Copy the prompt below into Claude Code (or any AI coding assistant) and it builds the feature
The implementation promptCopy, paste into your AI assistant
This prompt already encodes the implementation order, fallback paths, timeout value, and error handling. If you’re curious why it’s built this way, see Part A above.
Reference implementationWhat the AI will generate (Bun-based)
Three flagsWhy the prompt’s combination is safe and cheap
| Flag | Role |
|---|---|
| -p | Run as “one question → one answer” instead of an interactive session |
| –safe-mode | Blocks file read/write and command execution — returns pure text only, safe for handling untrusted input server-side |
| –model haiku | The fastest, cheapest model is plenty for lightweight tasks like name/category suggestions |
Want the same thing with Codex CLI? Here are the equivalent flags. They’re not a perfect 1:1 match, so the differences are noted too.
| Codex flag | Claude equivalent | Role · difference |
|---|---|---|
| exec “…” | -p | Run as “one prompt → one final answer” instead of an interactive session |
| –sandbox read-only | –safe-mode | Blocks writes and command execution. Codex still permits read access, though, so it’s not as fully locked down as --safe-mode — keep that in mind with untrusted input. |
| -o <file> | Regex-parsing stdout | --output-last-message writes the final answer straight to a file — no need to scrape a JSON block out of stdout with regex, which is arguably simpler. |
| -m <model> | –model haiku | Pin a low-cost model for lightweight work. Exact model names change often — check codex --help or ~/.codex/config.toml. |
Reuse what you
already have.
No API key to issue, no separate SDK to install — you’re simply repurposing the Claude Code already on your machine as an “AI engine.” It’s an especially useful pattern for personal local tools, so next time you want to bolt an AI feature onto a side project, just hand it the Part B prompt.
Reusing auth you already have beats building a new API.
댓글 남기기