Feature request: /fork should support opening in a new terminal tab

Status Open

Maintainer reply None cached

Activity 3 comments · opened Feb 8, 2026

Summary

The built-in /fork command creates a fork of the current conversation, but it stays in the same terminal. It should support opening the forked session in a new terminal tab.

Use case

When building a complex feature, I often need to branch into multiple thinking threads that share the same context but explore different angles:

Try different implementation approaches in parallel — "build it with approach A in one tab, approach B in another"
Explore tangential concerns without derailing the main thread — "how would this affect the auth system?" or "what if we need to support X down the line?"
Separate building from reasoning — keep the implementation moving in one tab while discussing architecture and long-term implications in another

These are multiple "discussion rooms" that share the same starting context but each need their own space. The workflow should be: hit /fork, a new tab opens with full context, and I'm immediately in a parallel conversation exploring a different angle — without interrupting the original session.

Currently this requires manually opening a tab, navigating to the directory, and resuming a forked session. The friction kills the flow.

Current workaround

I built a custom /fork-tab command that:

Echoes a unique token (which gets written to the session's .jsonl file)
Greps all session .jsonl files for that token to identify the current session ID
Uses AppleScript to open a new terminal tab and runs claude --resume <id> --fork-session

This works but is a hack — the token-grep approach is necessary because there's no way to access the current session ID from within a session (no env var, no API, process doesn't keep the .jsonl file open).

Proposal

Two changes that would make this much cleaner:

Expose CLAUDE_SESSION_ID as an environment variable in the bash tool subprocess. This eliminates the need for the token-grep hack and enables session-aware tooling.

Add a --new-tab flag to /fork (or a separate /fork-tab command) that opens the forked session in a new terminal tab, with support for Terminal.app and iTerm2.

View original on GitHub ↗

3 Comments

CosmoNaught · 6 months ago

Hey! I built a CLI tool (with TUI) that extends --fork-session into a full management layer: named snapshots you can branch from repeatedly, tree view of how context evolved, and a lossless trim that strips tool result bloat while keeping the full conversation.
Doesn't replace /fork but adds the naming, reuse, and cleanup that's missing. Hope it helps!

Open source: https://github.com/CosmoNaught/claude-code-cmv

carrotRakko · 5 months ago

Strongly agree with this proposal. I just ran into this exact friction today.

When I /fork, it's because I want to continue the original conversation and explore a different direction — two parallel threads from the same context. But the current behavior replaces the original session in my terminal, so I have to manually open a new tab and /resume to get back to it.

The /resume picker makes this even harder: sessions forked from the same conversation show nearly identical entries (same first message, similar size), so picking the right one becomes guesswork. Pick the wrong one and its "last activity" timestamp updates, making it even harder to distinguish next time.

Both proposals — CLAUDE_SESSION_ID env var and a --new-tab flag — would solve this cleanly. The env var alone would unblock custom tooling for power users.

✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)

lldxflwb · 5 months ago

+1 — I'd like to add two points that haven't been discussed yet.

Why `/btw` doesn't fill this gap

Claude Code already has /btw for quick side questions during an active session. However, /btw is intentionally limited:

No tool access — it can only answer from existing conversation context; it cannot read files, run commands, or search code
Single-turn only — no follow-up interaction
Context-only — cannot perform any new investigation

/btw is great for "what was that file name again?" but falls short when you need to actually do something — run a test, read a file, explore an alternative approach. /fork in a new terminal would fill this gap: full context + full tool access + multi-turn interaction, without blocking the original session.

The infrastructure already exists in Agent Teams

For users running teammateMode: "tmux" (or iTerm2 with tmux -CC), Agent Teams already spawn independent Claude Code instances in new tmux panes/windows. The terminal-spawning mechanism is proven and working.

/fork could reuse this same infrastructure. The delta is small: instead of spawning a fresh teammate with an empty context, spawn a forked session that inherits the current conversation history. This would make /fork feel like a first-class parallel workflow primitive rather than a session-ID trick that requires manual terminal management.