nntrivi2001
17d56d0e01
Clean break, no compatibility alias. Renames the product name, the CLI binary (`ccam` -> `agenthub`), the env var prefix (`CCAM_` -> `AGENTHUB_`), the Prometheus metric namespace (`ccam_*` -> `agenthub_*`), the tmux session prefix (`ccam-lane-<id>` -> `agenthub-lane-<id>`), the per-repo runtime profile directory (`.ccam/profile` -> `.agenthub/profile`), the lanes state root (`~/.claude/ccam-lanes` -> `~/.claude/agenthub-lanes`), the bundled plugins (`plugins/ccam*` -> `plugins/agenthub*`) and their slash commands (`/ccam-doctor` -> `/agenthub-doctor`, `/ccam:*` -> `/agenthub:*`). Because there is no alias, an existing install has to be updated by hand: rename its `.ccam/profile` directory and any `CCAM_*` variables, and reinstall the plugin under its new name. Two other name families are deliberately left alone here, since they are not just strings: the `Claude-Code-Monitor` repository/marketplace name, and the `agent-dashboard` npm package plus its `~/.claude/agent-dashboard` runtime directory, which holds the live database and needs a migration rather than a rename. Verified: server 1406/1406, client 459/459, `grep -i ccam` clean across tracked files, `openapi.yaml` regenerated (95 paths, unchanged count).
2.8 KiB
2.8 KiB
description
| description |
|---|
| Debug a specific session by inspecting its full event chain (PreToolUse, PostToolUse, Stop, SubagentStop, Compaction, APIError, TurnDuration, Notification events), agent hierarchy (recursive parent/child tree with subagent_type and depth), token usage with compaction baselines, workflow intelligence data (orchestration DAG, error propagation by depth), and session metadata (thinking_blocks, turn_count, total_turn_duration_ms). |
Session Debug
Debug and inspect a Claude Code session from Agent Monitor data.
Input
The user provides: $ARGUMENTS
This may be:
- A session ID to debug
- "latest" or "last" for the most recent session
- "errors" to find and debug the most recent errored session
Procedure
-
Identify the target session:
- If session ID given:
GET /api/sessions/{id}fromhttp://localhost:4820 - If "latest":
GET /api/sessions?limit=1(default sort: most recently updated first) - If "errors":
GET /api/sessions?limit=10&status=error
- If session ID given:
-
Collect full session data:
- Session metadata: status, model, cwd, timestamps, duration
- Events:
GET /api/events?session_id={session_id}— full event timeline - Agents:
GET /api/agents?session_id={session_id}— all agents in session - Cost:
GET /api/pricing/cost/{session_id}
-
Analyze the session:
Session Lifecycle
- Start time → first event → last event → end time
- Status transitions (active → working → completed/error)
- Total duration and active-vs-idle time
Event Chain Analysis
- Chronological event list with timestamps and durations
- Identify the critical path (longest chain of dependent events)
- Flag events that took unusually long
- Highlight error events with full error context
Agent Inspection
- List all agents: type, task, status, duration
- Subagent tree visualization (parent → children)
- Agents that failed and their last known state
- Agent switching patterns (when and why new agents spawned)
Tool Execution Trace
- Every tool invocation in order with: tool name, duration, success/failure
- Failed tool calls with error messages
- Tool retry patterns (same tool called multiple times)
Anomaly Detection
- Events out of expected order
- Gaps in event timeline (>30s with no events)
- Duplicate events or agent states
- Token usage spikes (compaction indicators)
-
Diagnosis:
- Root cause hypothesis (if errors present)
- Contributing factors
- Remediation suggestions
Output Format
Present as a debug report with:
- Session summary header (ID, status, model, duration, cost)
- Color-coded timeline (✅ success, ❌ error, ⚠️ warning, ℹ️ info)
- Agent tree diagram
- Diagnosis section with numbered findings