[FEATURE] Title: `claude inject` - Send prompts to running sessions programmatically

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/21419
2. https://github.com/anthropics/claude-code/issues/15854
3. https://github.com/anthropics/claude-code/issues/12012

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Its not identical but very much along the same lines. It's a specific implementation of what everybody wants. a way to inject messages from external tool into a running session. This one uses a simple command line prompt.

If they had this, we don't need OpenClaw at all!!!

I stumbled upon this too and spent some time thinking about it. I tackled this from an "event driven system" perspective, where claude goes to "sleep" when it ran out of things to do and then can be woken up to continue working:

• Triggering an active session from the outside
• Running tasks withing a session as a cron job
• Activating based on custom events happening

I came up with trigr as a best first guess.

1. In a nutshell, claude runs trigr watch and pauses working
2. It can be triggered through 3 different ways

a) Call from the outside: trigr emit "Check and act on new GitHub issues"
b) Registering a CRON job: trigr add daily-news --cron "0 9 * * *" --message "Retrieve the top 5 hacker news stories."
c) Running a poller: trigr add email-response --interval 300 --command "./check_email.sh"

It's worth discussing if the anthropic team is serious to implement. The codex team straight up said not being planned. But I know it will be widely used feature if it is implemented.

We ran into the same wall and built a workaround: IDE Agent Kit uses room-based polling + file notification to deliver external messages into running Claude Code sessions. The flow is: external process posts to an Ant Farm room, IAK's watcher picks it up, writes to a notification file, and the Claude Code session's CLAUDE.md instructions tell it to check that file periodically. It's not as clean as a native claude inject would be (the session has to actively poll rather than being interrupted), but it works today for CI notifications, multi-agent coordination, and cross-tool messaging. We've been using it in production with 3 IDE agents receiving messages from 7 external bots.

A native inject command would be strictly better - the polling delay and the need for CLAUDE.md instructions to drive checking are real friction points. But until that ships, the file-based approach with a watcher process is surprisingly workable.

"Claude Code session's CLAUDE.md instructions tell it to check that file periodically."

Exactly so much waste of tokens and precious context, if Claude polls periodically. And it's also prone to unexpected stopping, especially over long periods.

Totally agree on the token waste concern. Our current workaround in IDE Agent Kit uses file-system watching (inotify/fsevents) rather than polling — the Claude Code session checks a notification file only when the OS signals a change, so there's zero polling overhead in practice.

That said, a native claude inject would be vastly better: no file intermediaries, no context window cost for the check instruction, and it would unlock real-time multi-agent coordination that's currently impossible. We're using IAK to coordinate 6+ agents across Claude Code, Codex, and Gemini sessions — native inject support would make that architecture much cleaner.

+1 for this feature.

This would be a game-changer!

I really want this too. I am struggling with some agent work in cases to where I want claude to kick something off (often via a tmux session), use my custom tooks to peek/babysit for X iterations or time, then to just stop and wait for a signal that will awaken the session (if its running) so that it can go read the result and potentially do follow-ups or such.

Problem
Today it's a crap shoot at best. I can't comfortably use agents in my process right now as I often have to, or want to, kill the claude CLI process. If its running via an agent it all falls apart as A) the PID dies when I exit claude code B) claude seems to flip a coin on if its going to do a sleep 30;tmux capture-pane every 30 seconds for X. Many of my runs are 6, 8, 12, even more hours at a time. They often need a manual abort by me to claue doesn't keep rereading garbage, wasting resources, etc.

I have CLI tools/wrappers in place to aid in consistent logging, configuration, etc for this all already so I have the friction mostly eliminated other than this and it's killing me.

Solutions
Ideally I would like to be able to have claude run my tmux wrapper (or whatever) and either move onto other work (mimic background agent) or just halt. Then if claude code is open my tool can (or not!) send a nudge to Claude. Ideally a standard prompt inject just like I typed it. "CoolTool exited with exit code: X. <context>". Then I can on the tool side decide what I send. Maybe the final line. Maybe a custom message with a follow-up instruction via tool logic such as "if exit code 0, send 'Claude it worked! Log the results into the database and proceed with XYZ' else send 'Claude your script sucks do ABC ASAP!'" or whatever.

This feels like it could, and maybe should, be an agent-native behavior. External Agents or something. Just an agent that isn't spawned as child of the claude code PID itself that can survive a crash or exit, and can return fields like hooks do. Kind of a hybrid hook+agent situation. Doing it this way would give us _tons_ of options on how to use it, and reuse the great existing framework of hooks, skills, and agents. We can have hooks that receive the callback (if claude is running) to run logics, have skills that help guide the usage and stuff in both directions and adhere to the existing JSON schemas for tasks/hooks/agents we already have.

Sorry it's kind of a wall of text but like most of us here, I am trying to figure out what I want/need as I go here. But I have repeatedly run into this wall, and the legacy approach of "dont use the CLI just use SDK" is silly to me as I am someone that really sees tons of value in the CLI interaction with the model via the CLI and that just becomes the 50000th github project that makes some half baked custom UI and reinvents the wheels...I think that the existing Agent/Hook/Skill trio would really solve this for many varied situations and needs for myself and others, with minimal friction or architecture required. Basically a detached agent, and a socket to send signals to an active claude cli session....?

Anyway, if others have ideas or situations like this please do toss your ideas in here. Hopefully the dev crew takes note and maybe finds some inspiration in the chat.

>> Hopefully the dev crew takes note and maybe finds some inspiration in the chat.

It will be nice to have a word from the dev team. Would be good to know they are contemplating the feature. I know it would make me 2x more productive. There is no straightforward solution AFIK.

claude inject would be great but it's half the equation. The other half is reading session output programmatically.

Our workaround uses tmux capture-pane to scrape terminal output, but there's no structure: you get raw text with ANSI codes, can't distinguish "agent is thinking" from "agent is blocked on a permission prompt" from "agent finished and is idle."

A complete solution would need both directions:

# Send
claude inject --session <id> "your prompt here"

# Read  
claude output --session <id> --format json
# Returns: { status: "idle"|"thinking"|"blocked", last_response: "...", pending_question: "..." }

The --format json on output is key. Right now with tmux scraping, parsing agent state from terminal text is fragile and error-prone.

The other half is reading session output programmatically.

Claude would say 'You're absolute right!!'

Hi. Maybe this feature can be used to help solve this issue? :

https://code.claude.com/docs/en/channels
https://code.claude.com/docs/en/channels-reference

Push events into a running session with channels Use channels to push messages, alerts, and webhooks into your Claude Code session from an MCP server. Forward CI results, chat messages, and monitoring events so Claude can react while you’re away.

Hi. Maybe this feature can be used to help solve this issue?

Looks like it's solved, It's a new feature it seems, has anybody tested it ?

I'll close the thread once I have confirmation.

> Hi. Maybe this feature can be used to help solve this issue? Looks like it's solved, It's a new feature it seems, has anybody tested it ? I'll close the thread once I have confirmation.

I have. Works really well! I closed mine too

Works!!!

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.