Beacon

Guide · Claude Code

How to manage multiple Claude Code sessions

Parallel sessions stop helping when you spend the day reopening tabs, checking whether work finished, and reconstructing what each window was doing.

Download Beacon for macOSFree · no account
macOS 14 or later

The short answer: give every session a stable place, track whether it is working, blocked, finished or idle, and alert only when your action matters. The goal is not more windows—it is fewer manual checks.

The problem is attention, not process management

Claude Code already lets you run several sessions. The hard part begins after the second or third: one is executing tests, another has finished, one is waiting for permission, and the window in front of you hides all of that.

A terminal multiplexer or careful window layout can keep sessions organized, but neither tells you what changed while you were elsewhere. A useful control surface needs to answer two questions immediately: which session needs me now? and how do I get back to it?

Use four states, not a list of activity

Raw logs create another surface to monitor. A small state model is easier to scan:

Needs youBlocked on a question or permission. Work cannot continue until you respond.
Your moveThe turn finished and the result has not been acknowledged yet.
WorkingThe top-level session owns the turn. Nothing is being asked of you.
IdleThe session exists, but nothing is outstanding.

A practical parallel-session workflow

  1. Start sessions normally. Do not adopt a new worktree or orchestration method just to monitor them.
  2. Keep their positions stable. If items constantly reorder, every glance becomes a fresh search.
  3. Group by project. A subagent or background command belongs with the session that launched it, not as a new top-level project.
  4. Let blocked work interrupt; let completion notify once. Repeated completion alerts create noise, while a blocked session really cannot proceed.
  5. Return directly. A useful session manager should open the exact Claude Code session or terminal tab, not merely raise the host app.

How Beacon handles Claude Code

Beacon is a native macOS app that sits in a screen corner with one stable light per Claude Code or Codex session. Claude Code reports lifecycle changes through a small local hook. Beacon groups sessions by inferred project, shows live background-task context under the parent session, and returns to the exact session when the host exposes a safe route.

In the Claude desktop app, Beacon can return to the session directly. In Cursor and VS Code integrated terminals, its companion editor extension maps the session process to the exact terminal. In other terminals, Beacon uses the most specific route that terminal makes available and refuses to guess between ambiguous tabs.

Prompts, responses, code, session names, project names and file paths stay on your Mac. Optional telemetry contains bounded counts, timings and outcomes, and can be disabled in Settings.

What Beacon deliberately does not do

Beacon is not a worktree manager, prompt queue, agent launcher or prescribed methodology. That is intentional: it should make the Claude Code workflow you already chose easier to see and re-enter, rather than requiring you to move the work into Beacon.