여러 Claude Code 세션을 동시에 관리하는 법

Once you get used to Claude Code, terminal windows multiply. One fixes tests, another tidies documentation, a third drafts a refactoring plan. Throughput rises, but so does the cost: you forget which window is doing what, leave finished work unattended, and sometimes two sessions edit the same file and collide. This article breaks the problem into six axes (isolation, names, permissions, notifications, visibility and context) and gives habits grounded in the official documentation. It ends with ClaudeMiner, a process-level monitor, and its honest limits.

Choose the way you run in parallel

"Several at once" is not a single technique. The official docs describe worktrees, subagents, background sessions (agent view) and agent teams as different tools, and choosing the right one reduces management effort a lot.

This article centers on the approach most solo developers start with, several terminals plus worktrees, and treats the others as supporting tools.

One session, one task

The most effective rule is to give a session a single purpose. Mixing a bug fix, a new feature and a code review makes the conversation long and earlier context interferes with later work. When a task ends, wrap up the session and start the next one fresh. A one-line goal and a definition of done in the first prompt makes it easy to recover the context when you look at the window later.

Naming

Claude Code gives you several ways to name a session. At startup use claude -n auth-refactor; during a session use /rename auth-refactor; in the session picker highlight an entry and press Ctrl+R. A named session can be resumed with claude --resume auth-refactor or /resume auth-refactor. If another live session already uses the name, Claude Code keeps it with that session, gives yours a two-word suffix and tells you. Sessions you do not name get a generated title from your first prompt, but the docs say the default display name (working directory plus two characters) cannot be used to resume.

Coming back

• claude --continue reopens the most recent conversation in the current directory.
• claude --resume, or /resume inside a session, opens a picker. In it, Ctrl+W widens to all worktrees of the repository, Ctrl+A to every project on the machine, and Ctrl+B filters to the current git branch.
• To try another approach without losing the current path, use /branch name (or claude --continue --fork-session). The original stays intact.
• If you resume the same session in two terminals without forking, messages from both interleave in one transcript. If you want parallel work, fork.

Prevent file collisions with worktrees

When several sessions work in the same folder of the same repository, they overwrite each other's edits or read half-finished changes. A git worktree gives each branch its own working directory, which solves that directly, and Claude Code supports it with one flag.

claude --worktree feature-auth     # or -w feature-auth

By default Claude Code creates a new checkout at .claude/worktrees/feature-auth/ under the repository root on a new branch named worktree-feature-auth. If you omit the name, it generates one such as bright-running-fox. Running the same command with another name in a second terminal starts a second isolated session. A few things to know:

• You need at least one commit. A worktree is created from an existing commit, so in a repository with no commits you get Failed to resolve base branch "HEAD".
• The default base is the remote default branch. The documented default worktree.baseRef: "fresh" branches from the remote's default branch, usually main, so unpushed local commits and your in-progress feature branch state are not in the new worktree. Set it to "head" to branch from your current work. This trap is a common cause of "why is the code I just wrote missing in the worktree?"
• A new checkout means an empty environment. Reinstall dependencies; a gitignored .env does not come along. Put a .worktreeinclude file in the project root (gitignore syntax; only files that match and are also gitignored are copied) and they are copied into each new worktree.
• Add .claude/worktrees/ to .gitignore, as the docs recommend.
• Cleanup on exit: an unnamed session with no changes removes its worktree and branch automatically, a named session asks first, and if work remains you choose to keep or remove it. If you keep it, the claude --worktree <name> --resume command printed on exit brings you back.
• Limits of isolation: the checks cover edit tools, a command's working directory and git redirects, but the docs state they do not track files that cp or a shell redirect writes into the main checkout. Isolation is not absolute.

If you prefer plain git, create a folder with git worktree add ../project-feature-a -b feature-a and run claude there as usual. git worktree list shows them and git worktree remove cleans up. If two tasks must edit the same file, serializing them one session at a time hurts less at merge time than splitting them across worktrees.

Permission modes: different trust per session

With several sessions, they need not all share one permission mode. The official modes are below. Config values are English names, and the mode that asks about every action is displayed as "Manual" but its value is default.

Inside a session, Shift+Tab cycles modes. Per the docs, from auto the first press goes to default, then acceptEdits, then plan, and the status bar shows the current mode. At launch, pass for example claude --permission-mode plan. The docs also explain that deny rules apply even in bypassPermissions, and that writes to protected paths are not auto-approved except in that mode. When you resume from a terminal with --continue or --resume, the mode the session ended in is generally restored, but bypassPermissions is not, so it is safest to glance at the status bar after resuming.

My suggestion (an opinion from experience, not an official rule): run research and design sessions in plan, implementation sessions in their own worktrees in acceptEdits or auto, and anything touching production settings or deletions in default. Do not use blanket bypass flags such as --dangerously-skip-permissions outside a disposable container.

Do not miss "finished": hook notifications

The point of parallel work is doing something else while you wait, and walking between windows to check on progress throws that away. The most dependable option is Claude Code's own hooks, user-defined shell commands that run at specific points in its lifecycle. The docs' starter example adds a Notification hook to ~/.claude/settings.json; that event fires when Claude is waiting for input or permission. On macOS it looks like this.

{
  "hooks": {
    "Notification": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification \"Claude Code needs your attention\" with title \"Claude Code\"'"
          }
        ]
      }
    ]
  }
}

After saving, type /hooks at the prompt to see the registered hooks. To test, press Shift+Tab until Manual mode, ask for something that needs permission, and switch to another app to see whether a notification arrives. The docs warn about one pitfall: osascript routes notifications through Script Editor, and if that app lacks notification permission the command fails silently and macOS does not prompt you. If nothing appears, test with osascript -e 'display notification "test"' in a terminal first.

If you also want to know when a response finishes, use the Stop event (runs when Claude finishes responding). Add it as a sibling key in the same hooks object, taking care not to overwrite an existing hooks key.

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification \"Claude finished responding\" with title \"Claude Code\"'"
          }
        ]
      }
    ]
  }
}

With many sessions, having both alerts on can flood you and make you numb to them. I suggest keeping only the moment a person is needed (Notification) and using the completion alert only for long-running sessions. Turning on your terminal app's own bell or notification feature is another option.

One screen: agent view and external monitors

Agent view (claude agents)

The official claude agents command is described in the docs as a research preview, available in v2.1.257 or later, with an interface and shortcuts that may change. It shows background sessions, which run without holding a terminal, in a single table with the session name, a one-line summary of current activity, age and state. States are working, needs input, idle, completed, failed and stopped. You start a background session with claude --bg "prompt" or /bg inside a session. The key difference from external tools is that it reads Claude Code's own state and can tell you "needs input".

A process-level external monitor

If you run sessions the usual way in several terminal windows, there is a region agent view does not cover. A tool that tries to give a glance from operating-system process data is ClaudeMiner, introduced below. Even without a tool you can run something like ps -axo pid,tty,%cpu,command | grep '[c]laude' to see Claude Code processes and their terminal (TTY) column. On macOS a TTY of ?? suggests a process without a terminal.

Stuck sessions and zombie processes

When a session does not respond for a long time, first check whether it is really stuck; it may be running a big task or a slow command. If output stops and CPU stays at the floor, it may be waiting for input or hung. Separately, a process can remain after you close its terminal window. A process with no controlling terminal cannot be seen by anyone and easily becomes an orphan that only uses resources. Before terminating one, make sure it has no work in progress. Killing a process cannot be undone and unsaved conversation state may be lost.

Keep context small

As a conversation grows, both response quality and speed suffer. The documented tools inside a session are:

• /clear starts with an empty context. The previous conversation is saved and you can return with /resume.
• /compact [instructions] replaces history with a summary, optionally focused on what you specify.
• /context shows what is currently consuming context.
• Subagents: delegate research that reads many files; they read in their own context and return a summary.
• CLAUDE.md: write down build commands and rules you would otherwise repeat, so new sessions do not need them re-explained. Keep it short so important rules do not drown.

On Pro and Max plans, resuming a session that has been inactive for more than about an hour and is over 100,000 tokens can open a dialog asking whether to resume from a summary or as is, according to the docs. By then the prompt cache has expired and the first request reprocesses the full history, so for a long-idle session a summary or a fresh start is usually cheaper than continuing.

ClaudeMiner: a process-level monitor

ClaudeMiner is an open-source (MIT) monitor that shows each Claude Code process on your computer as a small character. It is made by SETLOG and is an independent project unaffiliated with the makers of Claude Code. The ClaudeMiner guide has the full walkthrough; here is only what matters in this article's context.

What it shows

• One icon and a PID for each detected Claude Code process, with counts for total, working, resting and zombie at the top.
• Per the project README, a process above 10% CPU is working, below 10% is resting, and one with no controlling terminal (TTY) is a zombie.
• It reads the process list at a configurable interval (2 seconds by default; 1, 2, 5 or 10 seconds), and on macOS can notify you when work finishes, a new session starts or a zombie appears, according to its docs. Clicking a PID copies it and zombies can be terminated from the app.

Honest limits

• CPU is an indirect signal. While Claude Code waits for a network response CPU is low and the miner may look like it is resting. Read "resting" as "currently using little CPU", not "finished".
• It cannot tell you which session is which. The app reads only process IDs and CPU and memory figures, not conversations or code, so session names, branches and task content are not shown. The PID is the only handle, so the naming and worktree habits above are still needed. As in the screenshot, labels can overlap when icons are close together.
• It cannot know "needs input". It is not a signal Claude Code gives itself, like agent view or a Notification hook. It cannot tell waiting for a human from resting after finishing.
• Platform coverage is narrow. The README download is a macOS build for Apple Silicon (.dmg). Windows 10 or later is listed in the requirements, but the project's internal docs say TTY detection is off on Windows, so zombie detection is most accurate on macOS. I could not confirm an Intel Mac build in the README.
• It is an observer only. It does not control Claude Code. The one exception is terminating zombies, which cannot be undone.

Starter checklist

1. Write down three tasks or fewer for the day and create a branch and worktree (claude -w name) per task.
2. Match session names (-n or /rename) to task names.
3. Start research sessions in plan, and implementation sessions inside worktrees in acceptEdits or higher.
4. Set a Notification hook and confirm it with /hooks.
5. For work that needs unpushed commits, check worktree.baseRef first.
6. When a task ends, merge, clean up the worktree, and /clear or close the session.
7. At the end of the day, review leftover sessions and unfamiliar processes with no TTY.

Sources and further reading

1. Claude Code Docs: Run parallel sessions with worktrees
2. Claude Code Docs: Manage sessions (naming, resume, branch, context commands)
3. Claude Code Docs: Automate actions with hooks
4. Claude Code Docs: Choose a permission mode
5. Claude Code Docs: Agent view (background sessions)
6. Claude Code Docs: Common workflows
7. Claude Code Docs: Best practices
8. ClaudeMiner GitHub repository (README, MIT license)

FAQ