With agentic coding becoming the primary paradigm for coding, many have tried to come up with a smooth subagent workflow.¹

Many of these solutions are reasonable, but none match the simplicity of what I actually want:

• Spin up another agent instance with the exact same context I’ve painstakingly built.
• Pursue a tangential thought interactively in a separate session.
• Sometimes that’s exploratory (understand a subsystem, ask follow-ups). Sometimes it’s parallel work (write tests while context is fresh, draft docs, spike an alternative).

That’s it. Open a new tab, resume the session, take a different path.

Sounds straightforward, but tack on a few more requirements and it becomes hard to find a satisfying solution. I’ve been using a thin shell script for this and it’s worked well.²

You can find the source here.

My requirements #

Super thin glue layer #

I’m deliberately not trying to build on top of existing agents. I use claude code, codex cli & gemini daily, and they change fast enough that anything with a thick layer (like a UI) will lag behind on features.

So: a Bash script and tmux. That’s it. Available on virtually any computer.

Tool-agnostic forks #

I want to start the main session in one tool and fork into another, keeping the same context.

So I might start a planning session with codex. After I have a decent plan, I might want to fork into claude code (with all the context I’ve built) and start a coding session. I might want to fork another subagent from gemini and, using something like the nanobanana MCP, build a before/after flow diagram.

Interactive, not one-shot #

When I fork a subagent, I want a real session I can keep interacting with. It’s rare that I can one-shot a request and get exactly what I want. Based on the initial response, I might want to go down the rabbit hole and explore more.

Many existing solutions are headless or try to merge results back automatically. In practice, I just copy-paste what I need from the fork back into the main session — tmux makes this trivial.

An early version of my script had something similar: the ability to manually “pull” in results from the subagents. In practice, I rarely used it that way. I typically copy-paste relevant lines from the agent response and paste them back into the main session. With tmux, if I highlight text with my mouse, it’s automatically copied to my clipboard. Removing this feature made the script simpler and more robust.

No context bloat #

The whole point of forking is keeping tangents out of the main session. I want the main session to stay focused on the “primary” change, while side quests happen elsewhere.

But I also want the context going into the forked subagent to be controlled. To that end, the script pulls in the text from the original window (courtesy of tmux) and checks the size. If the transcript is long, I summarize it before feeding it into the subagent.

In this way, the script keeps tangential context out of the main session while still seeding useful context to the subagent.

No personas #

Claude and other tools frame subagents around personas. I don’t find them as useful.

Don’t get me wrong, personas in prompts are powerful and can give good results. But I don’t need a subagent container for that. I find myself crafting specific agent skills and seeding those into the prompt. This gives me equally good results.

Label the subagents! #

Perhaps the trickiest part of having multiple agents working in parallel is keeping track of what each agent is doing.

My current solution to this is rather trivial. Every time an agent is spawned, I label the tmux window with something that will help me remember. It works rather well!

The solution #

Feel free to take a look at the Bash script here. You can also see my tmux.conf but there’s nothing special in there, and the subagent script should work with most configurations.

The script is conceptually pretty simple:

1. Start a coding session in tmux (as you regularly do).
2. Treat the current tmux pane as the main agent or session.
3. When you want to spawn a subagent, capture the transcript lines using tmux (configurable).
4. Prompt for the task you want to perform.
5. Spawn a new tmux window in the background with the chosen agent command, then paste in a payload:
   • <context> ... </context> (raw transcript, or an optional summary created with possibly a different agent)
   • <task> ... </task> (the prompt you typed)

Caveats #

• I’ve been tweaking this script for my own setup (Ghostty terminal + fish shell + tmux). I haven’t polished or tested it for any setup other than mine, but it should be straightforward to adapt.
• It’s easy to spawn too many forks. The marginal value drops quickly once you’re context-switching more than you’re building.
• Summarization is optional, but if you use it, you’re trusting a model to compress your transcript. If accuracy matters, keep the threshold low enough that the raw context fits.