This is obviously cool and useful so kudos, but wow security researchers have to throw their hands up all the time.
Now we open another attack surface where you can ask a remote agent to do things by default. There was a time when you call this a Remote Code Execution vuln. It's of course a feature here.
Like some others, I also built this myself. Overly simply, with tmux, a memory tree, and handoff files and an orchestrator. And yet for how simple it was, it was so effective at minimizing the amount of duplicate context. It's like having shared specialist subagents who source and derive important shared knowledge from separate threads. It's useful because some skills just take too much of a token penalty to invoke and a single shared persistent session just lets that issue melt away. One agent pays the cost of that large skill once, and you don't have to keep paying for it in input tokens for the rest of that conversation.
I was reading about the HF hack and one of the first thing the GPT swarm did was build a messaging system for themselves. This reminded me of that. (Also of how weirded out I was by Moltbook when it came out. Time flies!)
Unrelated: when my Claude/Codex finishes cooking (or needs my attention), it pings a local HTTP endpoint that plays a frog sound on my laptop. I found this massively boosts quality of life.
I haven't really shared this outside of my immediate circle, but I actually have a project like this. It plays on ~all events at the moment but has a special multi-tone sound when an agent is done or asking permission.
It's a cli that runs a server, a browser-based UI (where the audio happens), and a set of scripts to install hooks for various harnesses.
I built a general version of this, with global addresses and messaging between any terminal-based agent + MCP for browser agents. OSS if you want to run your own server at https://github.com/awebai/aweb and hosted version at https://aweb.ai
I'm fed up with compaction. I want my agent to get compacted but also retain full access to the prior conversation via search and tool calls - I want it to know "the requirements for X were discussed in detail previously in conversation C51E31CE-C985-4633-A749-DCC9805A7FEB" and have a tool that lets it dispatch a subagent to find those details again.
Hydra is an agent in spirit, but actually wraps other agents through ACP. It drives its own async compaction algorithm that gives the agent it wraps full access to history that it can search as an MCP server after compacting.
Generally works quite well but it allows nested subagents and that can use a lot of tokens if the agent prompts are too open-ended.
All messages are persisted as separate markdown files under a session directory, which makes them much more friendly to grep and such than the common jsonl files are. Agents can search them rapidly without messing around with jq.
Also written in Bash so it runs on any old potato you have laying around.
Claude Code makes agents reasonably aware of where their log files/history/etc are and get stored. Generally they’ll work with them without explicitly being told (especially to recover broken sub agents, corrupted sessions, etc) to do so.
I think the more general problem is that compaction is just a bandaid: you HAVE to dump context to keep going and searching back for it is more expensive than if you had just kept the right context. The better a job the harness does at filtering out junk, the more likely compaction is to remove context that might have been, forgive me, “load bearing”
IMO the default Claude Code / Codex (which to my understanding is almost continually-compacting?) compaction has got much better over the part few months. If you spam sub agents then context will naturally nest, and you can just resurrect them as needed without polluting the main thread.
Create your own protocol. I created a "wind down session" protocol my agents use that takes detailed notes in a "next_session_prompt.md" file that covers what was done this session, what is still open, and where they need to pick up the next session.
You can refine the protocol as you realize what's working and what isn't. I've been using that for months and it rarely drops important things now.
I do this a lot and you have to be really careful to clean these up or qualify/steer agents around them. They’ll often be very emphatically confident about some assumption or implication they made, and if another agent stumbles upon them they’ll get mislead.
They don’t really know what they’re handing off or what you’re trying to actually do, so in a sense it’s not a grounded task for them. Actually, if you think about it, any scenario in which a handoff doc might be valuable is probably almost always better as a subagent thread, because you are paying the same amount of read/write tokens but you can clear things up synchronously.
I’ve found two-way message passing (each get their own write file, they read each others) to work much better because the communication is more grounded in actual coordination/work. You can also give each an inbox so that multiple can write to it. If you do the “progressive disclosure” right it scales subquadratically because they only read/write to others when it’s relevant to what they’re working on.
But IMO “write a handoff” is a trap, as a human you end working in some kind of robot-graffiti codebase full of junk, and it ends up being a booby trap for agents literally within days.
I agree that if a sub agent could work then handoff is the wrong skill. These docs on the site agree too:
> What it buys is portability, not compression. That makes the skill narrower than it sounds. You need a file only when the work has to travel — to a new harness, a new directory, a colleague, or a side task you want to fork off. If nothing is travelling, you do not need a handoff: staying in the session, /clear, a subagent and /compact cover the ordinary end-of-phase case, and /compact covers it more often than this skill does.
With clean I mean the opposite of how I currently do it, which is by asking the model to compact the whole thread into a prompt which will act as context for next model.
My way of prompting this varies and every time I receive the blob of output, I can’t fell how well it managed to capture the necessary details. This way feels lika a dirty way to transfer knowledge from one conversation to another.
My largest issue is that when I'm looking for this I'm already dangerously close to autocompaction. And what I really want is a prompt which manages to preserve the most important parts of the chat log. And my opinion of important will not be the same as Claude, so we'll need to iterate on what that handoff really is.
I think what we really need is project/thread-scale continual learning. The problem is that the important parts of the conversation to you are the novel bits you just did, rather than all the context building the agent did to get to the point where it could do the novel bits (and even then, without really understanding the bigger picture).
If you snapshotted at 90% max context you could pretty reliably start iteratively trim that down, I think? I personally try to save the logs so agents can slice and dice them with sed/awk/jq/whatever when they need to look stuff up, because I’d rather pay the penalty on read (when it’s motivated by something) than in write(where you don’t really know what if anything will be needed), and they can figure out what they need on their own.
What I’d rather have is some way to bake history into the actual model weights (the same way it can recite certain literature or historical/factual stuff without context), with like multi-lora / “experts” that get trained out of band. But this is contrary to the “one fat model” approach to scaling and doesn’t work with closed labs’ business/IP models
I have built this with Claude as a script, but it can also message other models and get responses from them, and throughout my fleet of Linux machines via Tailscale. It's been mostly very useful, although occasionally you have to step in and interrupt if they start going the wrong way.
I built something similar for my team. I can share context between my own sessions as well as theirs. It's especially useful when debugging problems, so my context can benefit from theirs and vice versa.
Tried to have Claude demo this to me in the standalone Mac OS app. It didn't even know what I was talking about. Then I realized maybe it's only in CC. So I go over to CC and ask it to demo this functionality and it wants to demo via subagents. I correct it that I want separate chats to message each other. It tells me I need to open another Claude session in another terminal of course and just leave it sitting there. So I do that and it has me copy a message to the new conversation, it needed to like name itself or something internally.
It worked, but clunky. Way clunky compared to codex.
This is obviously cool and useful so kudos, but wow security researchers have to throw their hands up all the time.
Now we open another attack surface where you can ask a remote agent to do things by default. There was a time when you call this a Remote Code Execution vuln. It's of course a feature here.
Like some others, I also built this myself. Overly simply, with tmux, a memory tree, and handoff files and an orchestrator. And yet for how simple it was, it was so effective at minimizing the amount of duplicate context. It's like having shared specialist subagents who source and derive important shared knowledge from separate threads. It's useful because some skills just take too much of a token penalty to invoke and a single shared persistent session just lets that issue melt away. One agent pays the cost of that large skill once, and you don't have to keep paying for it in input tokens for the rest of that conversation.
Does this work for different harnesses like Codex and Antigravity?
codex has been able to send messages across threads for a long time
I was reading about the HF hack and one of the first thing the GPT swarm did was build a messaging system for themselves. This reminded me of that. (Also of how weirded out I was by Moltbook when it came out. Time flies!)
Unrelated: when my Claude/Codex finishes cooking (or needs my attention), it pings a local HTTP endpoint that plays a frog sound on my laptop. I found this massively boosts quality of life.
How do you know when they’re done (or need your attention)? Is that a standard “api”/hook? I want that!
I haven't really shared this outside of my immediate circle, but I actually have a project like this. It plays on ~all events at the moment but has a special multi-tone sound when an agent is done or asking permission.
It's a cli that runs a server, a browser-based UI (where the audio happens), and a set of scripts to install hooks for various harnesses.
https://github.com/neiltron/bingbong
I have no idea, I just asked both of them to add the hook to themselves.
All agents I know of have a hook system that can call arbitrary scripts.
I built a general version of this, with global addresses and messaging between any terminal-based agent + MCP for browser agents. OSS if you want to run your own server at https://github.com/awebai/aweb and hosted version at https://aweb.ai
I wish there was a clean way to compact the conversation into a prompt with all necessary context for a new fresh conversation.
I'm fed up with compaction. I want my agent to get compacted but also retain full access to the prior conversation via search and tool calls - I want it to know "the requirements for X were discussed in detail previously in conversation C51E31CE-C985-4633-A749-DCC9805A7FEB" and have a tool that lets it dispatch a subagent to find those details again.
Do any of the coding agents have this already?
Hydra is an agent in spirit, but actually wraps other agents through ACP. It drives its own async compaction algorithm that gives the agent it wraps full access to history that it can search as an MCP server after compacting.
https://github.com/smagnuso/hydra-acp
This one does agentic search instead of compaction: https://github.com/wedow/harness
Generally works quite well but it allows nested subagents and that can use a lot of tokens if the agent prompts are too open-ended.
All messages are persisted as separate markdown files under a session directory, which makes them much more friendly to grep and such than the common jsonl files are. Agents can search them rapidly without messing around with jq.
Also written in Bash so it runs on any old potato you have laying around.
Claude Code makes agents reasonably aware of where their log files/history/etc are and get stored. Generally they’ll work with them without explicitly being told (especially to recover broken sub agents, corrupted sessions, etc) to do so.
I think the more general problem is that compaction is just a bandaid: you HAVE to dump context to keep going and searching back for it is more expensive than if you had just kept the right context. The better a job the harness does at filtering out junk, the more likely compaction is to remove context that might have been, forgive me, “load bearing”
IMO the default Claude Code / Codex (which to my understanding is almost continually-compacting?) compaction has got much better over the part few months. If you spam sub agents then context will naturally nest, and you can just resurrect them as needed without polluting the main thread.
“Search session history for when we discussed XYZ”
https://github.com/nerdyaustin/memory_mcp
You can skip all the sync stuff, not necessary at all
Both CC as well as grok build for me seem to know about the log file location and they just read off the context from there
Create your own protocol. I created a "wind down session" protocol my agents use that takes detailed notes in a "next_session_prompt.md" file that covers what was done this session, what is still open, and where they need to pick up the next session.
You can refine the protocol as you realize what's working and what isn't. I've been using that for months and it rarely drops important things now.
Have you tried Matt Pocock's "handoff" skill?
https://github.com/mattpocock/skills/blob/main/skills/produc...
> Write a handoff document summarising the current conversation so a fresh agent can continue the work. > […]
I do this a lot and you have to be really careful to clean these up or qualify/steer agents around them. They’ll often be very emphatically confident about some assumption or implication they made, and if another agent stumbles upon them they’ll get mislead.
They don’t really know what they’re handing off or what you’re trying to actually do, so in a sense it’s not a grounded task for them. Actually, if you think about it, any scenario in which a handoff doc might be valuable is probably almost always better as a subagent thread, because you are paying the same amount of read/write tokens but you can clear things up synchronously.
I’ve found two-way message passing (each get their own write file, they read each others) to work much better because the communication is more grounded in actual coordination/work. You can also give each an inbox so that multiple can write to it. If you do the “progressive disclosure” right it scales subquadratically because they only read/write to others when it’s relevant to what they’re working on.
But IMO “write a handoff” is a trap, as a human you end working in some kind of robot-graffiti codebase full of junk, and it ends up being a booby trap for agents literally within days.
I agree that if a sub agent could work then handoff is the wrong skill. These docs on the site agree too:
> What it buys is portability, not compression. That makes the skill narrower than it sounds. You need a file only when the work has to travel — to a new harness, a new directory, a colleague, or a side task you want to fork off. If nothing is travelling, you do not need a handoff: staying in the session, /clear, a subagent and /compact cover the ordinary end-of-phase case, and /compact covers it more often than this skill does.
https://www.aihero.dev/skills-handoff
(Emphasis mine)
Just make a new slash command with those instructions as the prompt.
There is, but your wish of "clean" is ambiguous.
Here's a view for "clean:"
1. Every chat should have a context used/remaining measurement so you know when you have to ditch the current chat for a fresh one.
2. Every chat should analyze and categorizes each element of context by how useful it is towards the overarching goal of the chat.
3. Every chat has a handoff button with a "usefulness" slider (say 1-5) that shows the total size of the context based on its setting.
4. The handoff automatically creates a new chat with the desired amount of context and a prompt to get it back to where you were.
That said, I am newb and so there is some reason why these non-deterministic LLMs can't do this :-/
With clean I mean the opposite of how I currently do it, which is by asking the model to compact the whole thread into a prompt which will act as context for next model.
My way of prompting this varies and every time I receive the blob of output, I can’t fell how well it managed to capture the necessary details. This way feels lika a dirty way to transfer knowledge from one conversation to another.
You said there is? What’s the options?
My largest issue is that when I'm looking for this I'm already dangerously close to autocompaction. And what I really want is a prompt which manages to preserve the most important parts of the chat log. And my opinion of important will not be the same as Claude, so we'll need to iterate on what that handoff really is.
I think what we really need is project/thread-scale continual learning. The problem is that the important parts of the conversation to you are the novel bits you just did, rather than all the context building the agent did to get to the point where it could do the novel bits (and even then, without really understanding the bigger picture).
If you snapshotted at 90% max context you could pretty reliably start iteratively trim that down, I think? I personally try to save the logs so agents can slice and dice them with sed/awk/jq/whatever when they need to look stuff up, because I’d rather pay the penalty on read (when it’s motivated by something) than in write(where you don’t really know what if anything will be needed), and they can figure out what they need on their own.
What I’d rather have is some way to bake history into the actual model weights (the same way it can recite certain literature or historical/factual stuff without context), with like multi-lora / “experts” that get trained out of band. But this is contrary to the “one fat model” approach to scaling and doesn’t work with closed labs’ business/IP models
I have built this with Claude as a script, but it can also message other models and get responses from them, and throughout my fleet of Linux machines via Tailscale. It's been mostly very useful, although occasionally you have to step in and interrupt if they start going the wrong way.
I built something similar for my team. I can share context between my own sessions as well as theirs. It's especially useful when debugging problems, so my context can benefit from theirs and vice versa.
I hacked this together with a small local irc server
This sounds cool
In fact, I don't understand what is this feature‘s difference between CMUX & Orca?
I asked cc the best pattern for this in a frontend + backend project just days ago and it suggested mcp server on backend
Tried to have Claude demo this to me in the standalone Mac OS app. It didn't even know what I was talking about. Then I realized maybe it's only in CC. So I go over to CC and ask it to demo this functionality and it wants to demo via subagents. I correct it that I want separate chats to message each other. It tells me I need to open another Claude session in another terminal of course and just leave it sitting there. So I do that and it has me copy a message to the new conversation, it needed to like name itself or something internally.
It worked, but clunky. Way clunky compared to codex.
The simplest version of this is to just tell two sessions to coordinate by taking turns appending to a markdown file.
I've used this feature and saw some weird messages:
> hold swarm, I prepare safe exfil
Curious, Windows is not supported by this.
i miss when opencode let you interact with your subagents. that was so so so much better.
I broadly miss this feature to allow user agency, in letting users work with the various agents at they please, and to send data around.
Claude Code does allow this. You can talk to the subagents directly and watch what they are doing.