Claude Code added this new feature: claude agents –json` to list live Claude sessions as JSON for scripting. But it’s so abstract, what does it mean and how I can utilize it to better my workflow?

What claude agents –json Does

It outputs all your active Claude sessions in JSON format, making it easy to:

• Script automation around Claude sessions
• Build custom session pickers
• Integrate with terminal multiplexers (tmux, screen)
• Create status bar widgets
• Resurrect sessions after restarts Basic Usage claude agents –json This will output something like:

 [
    {
      "id": "session-abc123",
      "name": "Working",
      "status": "active",
      "created": "2026-05-20T10:30:00Z",
      "directory": "C:\\Users\\ncarucci\\Documents\\Gitfolder\\Working"
    },
    {
      "id": "session-def456",
      "name": "xxxxx-fundoffunds",
      "status": "idle",
      "created": "2026-05-20T09:15:00Z",
      "directory": "C:\\Users\\ncarucci\\Documents\\Gitfolder\\xxxx-fundoffunds"
    }
  ]

We can use it for session picker, list active sessions with status, find sessions by directory, tumux integration (session resurrection), status bar widget, automate session cleanup, export session details. To illustrate, here are practical custom scripts for my workflow:

1. Project Session Switcher (Most Useful) Switch between your different project directories with one command:

  # PowerShell: claude-switch.ps1
  $sessions = claude agents --json | ConvertFrom-Json

  # Group by directory
  $projects = $sessions | Group-Object -Property cwd | ForEach-Object {
      @{
          Project = ($_.Name | Split-Path -Leaf)
          Path = $_.Name
          Sessions = $_.Count
          Status = $_.Group[0].status
          SessionId = $_.Group[0].sessionId
      }
  }

  # Display menu
  $projects | ForEach-Object { Write-Host "$($projects.IndexOf($_) + 1). $($_.Project) - $($_.Status)" }
  $choice = Read-Host "Select project"
  $selected = $projects[$choice - 1]

  Write-Host "Switching to $($selected.Project)..."
  claude attach $selected.SessionId

2. Auto-Resume Index Construction Session Quick script to resume work on a specific index project:

  # claude-index-resume.ps1
  param(
      [string]$IndexName = "202603_ChipMemory"
  )

  $sessions = claude agents --json | ConvertFrom-Json
  $indexSession = $sessions | Where-Object { $_.cwd -match $IndexName }

  if ($indexSession) {
      Write-Host "Resuming $IndexName..."
      claude attach $indexSession.sessionId
  } else {
      Write-Host "No active session for $IndexName, starting new one..."
      cd "C:\Users\ncarucci\Documents\Gitfolder\Working$IndexName"
      claude
  }

3. Session Dashboard (Real-time Status Monitor) Shows all Claude sessions with details at a glance:

4. Auto-Kill Idle Sessions (Resource Management) Automatically close idle sessions after a timeout:

5. Git Integration – Auto-Create Session per Branch When you switch git branches, auto-open Claude for that project:

6. Session Backup & Restore (Like tmux-resurrect) Save/restore all active sessions:

7. Focused Work Mode (Close all but one session) When you need to focus on one project, close other idle sessions:

8. Task-Based Session Manager (For Index Construction Workflow) Map specific tasks to sessions:

whether I should adopt this new feature? Current Approach (Memory + Skills/Plugins)

Pros:

• Persistent across restarts – Memory survives computer sleep, crashes, session close
• Project narrative – Memory files document decisions, methodology, validated patterns
• Context-independent – Works regardless of how many sessions are open or closed
• Recoverable – If something breaks, memory + code tell you what was done
• Knowledge capture – Skills/plugins encode reusable domain logic (RBICS tool, backtest patterns)
• Ideal for index construction – Long methodologies that survive restarts

Cons:

• Manual session setup each time
• No real-time status of work-in-progress
• Can’t quickly see “what am I currently working on?”
• Not ideal if you’re parallelizing work across multiple projects

claude agents –json Approach (Session Management)

Pros:

• Quick project switching – If 2 index projects are active, switch instantly
• Real-time status – See which sessions are busy vs idle
• Active session awareness – Know if something is still running
• Good for parallel work – Track multiple simultaneous projects
• Automation – Monitor, cleanup, integrate with terminal multiplexers (tmux)
• Long-running visibility – See if background queries/deploys are still processing

Cons:

• Sessions are ephemeral – Close Claude or restart = session gone (memory doesn’t help here)
• Doesn’t solve recovery – If you close all sessions, you start from scratch
• Requires sessions to stay alive – If you shut down your machine, sessions die
• Doesn’t capture methodology – Session metadata doesn’t tell you why you made decisions
• Doesn’t help with reusable tools – RBICS classifier isn’t stored in sessions
• Single-person overhead – More useful for teams juggling multiple projects

For Your Specific Workflow (Index Construction) You should NOT switch to agents –json if:

• You work on one index at a time (sequential)
• You need to survive restarts and crashes
• You’re documenting methodology and decisions
• You’re reusing domain knowledge across projects You SHOULD use agents –json if:
• You’re working on 3+ index projects simultaneously
• You need to quickly see “which project is currently running?”
• You want to automate cleanup (kill idle sessions after 2 hours)
• You’re using tmux and want to resurrect sessions on terminal restart Honest Recommendation for Your Use Case Stick with what you have. Your memory + skills approach is better because:

You’re already optimized – Your CLAUDE.md + memory structure is exactly what this workflow needs Hybrid Approach (If Useful Later) If you ever do parallel work (2 indices simultaneously), combine both: Still use memory for recovery, add this for quick switching $sessions = claude agents –json | ConvertFrom-Json
$memoryPath = “$env:USERPROFILE.claude\projects*\memory\MEMORY.md” Show sessions + memory context $sessions | ForEach-Object {
$project = $_.cwd | Split-Path -Leaf
$memory = Get-ChildItem $memoryPath | Where-Object { $_.FullName -match $project } | Get-Content | Select-Object -First 3
Write-Host “$project – $($_.status)”
} But for now? Don’t add this complexity. Your current setup is solid for single-person, methodology-heavy index construction work.

• Index construction is sequential – You focus on one index, finish it, move to next
• Recovery is critical – Your methodology documents are more valuable than session state
• Reusability matters – RBICS tool, backtest patterns, supply chain logic exist in code/memory, not sessions
• Documentation is key – Memory files explain why you chose certain RBICS L6 codes