Feature request: desktop notification when prompt is idle

[timvisher-dd]

When an agent turn completes and I'm not looking at the buffer, I have no way to know it's waiting for input. Claude Code now sends idle notifications by default, and I'd like agent-shell to do the same.

Proposed behavior

• After a turn completes, start a configurable idle timer (e.g. 30s).
• If the user interacts with the buffer before the timer fires, cancel it.
• Otherwise, send a desktop notification. Also log to the echo area if the shell buffer is not the active buffer.
  • In GUI Emacs, send a native desktop notification.
  • In terminal Emacs, use OSC escape sequences to trigger the terminal's built-in notification feature where supported. Wrap in tmux DCS passthrough when inside tmux.
  • Fall back to an echo area message when no OS-level notification path is available.

Windows and Linux

I don't have regular access to either platform, so when the terminal is unknown the current implementation just falls back to the echo area message (no OS-level notification). Happy to accept input on what the right defaults should be there — e.g. notify-send on Linux, powershell toast notifications on Windows, etc.

Checklist

• I agree to communicate with the author myself (not AI-generated).
• I've read the README's Filing issues section.
• I'm running the latest versions (fill in below).
  • agent-shell: latest main
  • acp.el: latest main
  • ACP package (e.g. claude-code-acp): latest
  • Agent CLI (e.g. claude, gemini): latest
• For requesting new agent support, I'm including a link to the ACP-capable agent or related ACP package. N/A
• For issues, I'm including ACP traffic (as per README). N/A

[emil-e]

I'm not entirely sure that a package within Emacs should take responsibility for notifying OS level facilities. But it's easy to build your own solution for this after the merge of this PR of mine: #382

Personally, I have notifications per tab rather than notification on the OS level, so I'm not convinced that OS level notification is what people actually want in general.

[timvisher-dd]

I'm not entirely sure that a package within Emacs should take responsibility for notifying OS level facilities.

That's an interesting stance to take. Why wouldn't Emacs be able to take advantage of system level notifications? My perspective is that it's a program running in my OS and having it integrate with that OS make my usage of it more convenient. What's your perspective?

But it's easy to build your own solution for this after the merge of this PR of mine: #382

Neat! It was already pretty easy to build my own solution with what existed but this changeset makes it even easier. 👏

Personally, I have notifications per tab rather than notification on the OS level, so I'm not convinced that OS level notification is what people actually want in general.

Can you tell me more about what you mean by 'I have notifications per tab rather than notification on the OS level'? What's 'per tab' mean in that case?

[timvisher-dd]

I'm not convinced that OS level notification is what people actually want in general.

I should also state explicitly that I'm not opposed to this being a customization. If there's obvious community desire for it to behave both ways then introducing it behind an option would be fine with me.

[xenodium]

Thanks for filing.

With the new event subscription APIs, it's fairly straightforward to add and enables users to pick their preferred notification style/method.

With that in mind, this can easily live in a separate package. I'd be happy to link to a notification package in the related packages section of the README.

[timvisher-dd]

Thanks for filing.

With the new event subscription APIs, it's fairly straightforward to add and enables users to pick their preferred notification style/method.

With that in mind, this can easily live in a separate package. I'd be happy to link to a notification package in the related packages section of the README.

👂 Can't say I'm not disappointed in that decision as it's a decently small amount of code to get better-than-parity with claude's native experience but I respect it nonetheless. I didn't know how much I wanted this until I used claude directly for a brief time and realized how nice it is.

What're your feelings on the agent-shell prefix? This'll be the second agent-shell library I've spun out (agent-shell-mcp-oauth being the first which is private and already deprecated because of agentclientprotocol/claude-agent-acp#411) and my inclination is to do that here as well (probably agent-shell-idle-prompt-os-notifications or summat). Is that OK with you?

---

On a more personal note one thing I'm having trouble with organizationally is how rapidly we're spinning out libraries here. It's a big headache as I've been working on these projects to always have to be keeping agent-shell, shell-maker, and acp.el in sync and I'm not sure I see the benefit. It seems that shell-maker and acp.el were built first and foremost to be used by agent-shell although obviously they are generically useful. agent-shell is a very small code base even considering shell-maker and acp.el as part of it and other libraries/packages have waited until they're orders of magnitude larger before splitting out formal packages.

I think at this stage of the project it would make more sense to put all eggs in agent-shell and only split out libraries later when there's very clear need to do so. It would simplify development in an extremely fast moving space. https://signalvnoise.com/svn3/the-majestic-monolith/

[emil-e]

I'm not entirely sure that a package within Emacs should take responsibility for notifying OS level facilities.

That's an interesting stance to take. Why wouldn't Emacs be able to take advantage of system level notifications? My perspective is that it's a program running in my OS and having it integrate with that OS make my usage of it more convenient. What's your perspective?

I'm not saying Emacs shouldn't integrate with the OS, but I think that is the job of Emacs, rather than agent-shell. I think agent-shell should use the facilities provided my Emacs so that it plays well with how each user has set it up. This is just my opinion though, I am not affiliated with agent-shell, just a rando on the interwebs.

Can you tell me more about what you mean by 'I have notifications per tab rather than notification on the OS level'? What's 'per tab' mean in that case?

I have a tab-per-project system in my Emacs config and it has a feature to flag the tab as needing attention by blinking the tab icon to a bell icon instead. I hooked this into agent-shell events, which is why I submitted the PR.

[xenodium]

👂 Can't say I'm not disappointed in that decision as it's a decently small amount of code to get better-than-parity

gh pr diff 407 --repo xenodium/agent-shell | diffstat
 agent-shell-alert.el       |  236 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 agent-shell.el             |  162 +++++++++++++++++++++++++++++++++++++++++++++
 bin/test                   |   79 ++++++++++++++++++++++
 tests/agent-shell-tests.el |  328 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 804 insertions(+), 1 deletion(-)

804 lines of code is not a small amount of code to inherit.

What're your feelings on the agent-shell prefix?

All good, please qualify it further. Looks like you're already doing that, using agent-shell-alert prefix in #407. Thanks for the PR, but this can live in a separate repository. As I mentioned, I'd be happy to link to your project from the README.

On a more personal note one thing I'm having trouble with organizationally is how rapidly we're spinning out libraries here.

• shell-maker was spun out of chatgpt-shell in October, 2024 (but created much earlier in April 2023).
• acp.el launched in September, 2025.
• agent-shell launched soon after also in September, 2025.

First two are a year apart. I would have happily kept acp.el as part of agent-shell, but with all the non-UI duplication we all did in the first wave of AI packages (gptel, chatgpt-shell, ollama buddy, etc), a UI-agnostic acp.el was the right call here. I can't win though.

It seems that shell-maker and acp.el were built first and foremost to be used by agent-shell

Not really. shell-maker is used by the following packages, way before agent-shell came into existance.

• chatgpt-shell - A family of utilities to interact with LLMs (ChatGPT, Claude, DeepSeek, Gemini, Kagi, Ollama, Perplexity)
• claude-shell - Integration with Anthropic's Claude LLM
• copilot-chat - Copilot chat interface
• dall-e-shell - Interaction mode for DALL-E
• kagi - Kagi API integration
• qwen-chat-shell - Qwen-chat shell + buffer insert commands

I think at this stage of the project it would make more sense to put all eggs in agent-shell

Not really feasible.

[timvisher-dd]

What're your feelings on the agent-shell prefix?

All good, please qualify it further. Looks like you're already doing that, using agent-shell-alert prefix in #407. Thanks for the PR, but this can live in a separate repository. As I mentioned, I'd be happy to link to your project from the README.

Sounds good. :)

Shall I keep this issue open and we'll close it if/when I have the library available and we've linked it?

On a more personal note one thing I'm having trouble with organizationally is how rapidly we're spinning out libraries here.

• shell-maker was spun out of chatgpt-shell in October, 2024 (but created much earlier in April 2023).
• acp.el launched in September, 2025.
• agent-shell launched soon after also in September, 2025.

First two are a year apart. I would have happily kept acp.el as part of agent-shell, but with all the non-UI duplication we all did in the first wave of AI packages (gptel, chatgpt-shell, ollama buddy, etc), a UI-agnostic acp.el was the right call here. I can't win though.

It seems that shell-maker and acp.el were built first and foremost to be used by agent-shell

Not really. shell-maker is used by the following packages, way before agent-shell came into existance.

• chatgpt-shell - A family of utilities to interact with LLMs (ChatGPT, Claude, DeepSeek, Gemini, Kagi, Ollama, Perplexity)
• claude-shell - Integration with Anthropic's Claude LLM
• copilot-chat - Copilot chat interface
• dall-e-shell - Interaction mode for DALL-E
• kagi - Kagi API integration
• qwen-chat-shell - Qwen-chat shell + buffer insert commands

I think at this stage of the project it would make more sense to put all eggs in agent-shell

Not really feasible.

Ah cool I was not aware of all the community usage. Thanks for hipping me to it. I guess the ship sailed. :)

[timvisher-dd]

👂 Can't say I'm not disappointed in that decision as it's a decently small amount of code to get better-than-parity

gh pr diff 407 --repo xenodium/agent-shell | diffstat
 agent-shell-alert.el       |  236 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 agent-shell.el             |  162 +++++++++++++++++++++++++++++++++++++++++++++
 bin/test                   |   79 ++++++++++++++++++++++
 tests/agent-shell-tests.el |  328 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 804 insertions(+), 1 deletion(-)

804 lines of code is not a small amount of code to inherit.

Gently it's 162 lines of functional code and the rest are tests. I know that tests are code too and add to the weight of the overall repo but I don't think it's entirely fair to state that this was 804 lines of code.

Features require code. Again I mean this gently and as someone who really wants agent-shell to succeed and is pouring hours of my own time into as well but the overall attitude I feel like I've gotten back so far is a deep skepticism of additional features in agent-shell/shell-maker/acp.el. That's a fine position to take but I think overall it will needlessly hamper the project rather than make it the best agent interaction facility which IMO it currently is.

If you want agent-shell to freeze in place because it's too much to maintain again it's already great and I can extend it as I see fit (hurray emacs) but I don't want to see that happen. I'd prefer to have a thriving community that's adding generally beneficial features at a reasonable pace.

I'm really not trying to complain here. I am on the other hand trying to be honest about my experience so far trying to contribute to the project. Take it as you will and I really do appreciate your stewardship and efforts!

[xenodium]

Shall I keep this issue open and we'll close it if/when I have the library available and we've linked it?

SGTM

[xenodium]

Gently it's 162 lines of functional code and the rest are tests. I know that tests are code too and add to the weight of the overall repo but I don't think it's entirely fair to state that this was 804 lines of code.

Code is code and if I inherit it, I maintain it.

Features require code. Again I mean this gently and as someone who really wants agent-shell to succeed and is pouring hours of my own time into as well but the overall attitude I feel like I've gotten back so far is a deep skepticism of additional features in agent-shell/shell-maker/acp.el.

I met a user recently who was concerned about agent-shell bloating. Again, I can't win.

That's a fine position to take but I think overall it will needlessly hamper the project rather than make it the best agent interaction facility which IMO it currently is.

AI moves fast. Some things stick and some don't. I'm comfortable with not being on the bleeding edge.

If you want agent-shell to freeze in place because it's too much to maintain again it's already great and I can extend it as I see fit (hurray emacs) but I don't want to see that happen. I'd prefer to have a thriving community that's adding generally beneficial features at a reasonable pace.

Not everything needs to go into agent-shell itself. Supporting packages can happily co-exist.

I'm really not trying to complain here. I am on the other hand trying to be honest about my experience so far trying to contribute to the project. Take it as you will and I really do appreciate your stewardship and efforts!

I'm happy for some contributions to live in agent-shell. Others can live as separate packages. Unfortunately, I won't be able to accept all contributions into the package. On the upside, the code is available to all and Emacs moldability enables both to have the cake and eat it too.

[xenodium]

Been playing with the subscriptions/notifications in a separate package https://github.com/xenodium/agent-shell-knockknock