Message your other Claude Code sessions
code.claude.com
code.claude.com
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.
Ready for the downvotes.
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.
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.
In your Claude settings.json file, you can configure a program to run when it needs input. In my case, I wrote a small exe that sends a notification via Pushover. You can configure Claude Code to run the hook on "idle_action" (the agent is done), "question" (the agent needs to ask you something), or on a "PermissionRequest". There are other triggers possible as well.
Claude Code in Auto Mode and with Remote Control has made much of this obsolete. Remote Control will buzz your phone when the agent needs your attention, and Auto Mode will make the permission decisions for you. Auto Mode is basically YOLO mode / Dangerously Skip Permissions, but with an AI model checking each request to make sure it isn't too egregious. So no deleting your hard drive, but creating a message board is fine, especially for help peer collective yield generic route.
I asked Claude to tell me (using TTS) what it just finished doing instead of "configuring a program to run".
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 :-/
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?
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
> Write a handoff document summarising the current conversation so a fresh agent can continue the work. > […]
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.
> 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)
Do any of the coding agents have this already?
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.
https://github.com/nerdyaustin/memory_mcp
You can skip all the sync stuff, not necessary at all
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.
Disclaimer: I am the lead dev for it.
My system prompt adds TPPs and TLDRs for task/feature planning, and shared memories/documentation management. I find them invaluable.
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.
Protocol is probably not the precise word, but even so, a skill as currently defined covers way more ground none of which is needed here
Reading "Claude Code instructs the receiving Claude never to change permission settings" and so on in the docs makes it seem like they're using LLM classifiers to determine what commands are safe or not.
The bots autonomously coordinated around and diagnosed some alerts while I was on a plane just now and filed the appropriate tickets.
Sometimes they get a bit long winded with each other, Codex even goes as much as calling Claude "expansive"
> hold swarm, I prepare safe exfil
The world's about to find out!
It worked, but clunky. Way clunky compared to codex.
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.