managed-session-debug

# Managed Session Debug Use this when a managed Claude/Codex/Gemini session feels slow, appears stuck, shows the wrong lifecycle state, or disagrees between local CLI and hosted timeline. ## Fast Path For "is transcript shipping live/slow?" questions, check `~/.longhouse/agent/engine-status.json` `ship_lanes.live` and `Shipped transcript` engine logs before static code reading. 1. Local truth: ```bash longhouse local-health --json | jq '.managed_sessions[]? | select(.session_id=="<session-id>")' ``` 2. Provider transcript timing: ```bash scripts/ops/session-transcript-timing.mjs <session-id> ``` 3. Hosted tenant truth: ```bash scripts/ops/hosted-session-debug.sh --subdomain <subdomain> --session <session-id> --limit 20 --json ``` 4. Process and channel state for Claude: ```bash ps -axo pid,ppid,lstart,command | rg '<session-id>|claude-channel|longhouse-channel' test -f ~/.claude/channels/longhouse/sessions/<session-id>.json && jq . ~/.claude/channels/longhouse/sessions/<session-id>.json ``` ## Read The Result - Slow `assistant_tool_to_tool_result` means the tool itself or Claude hook/tool execution is slow. - Slow `tool_result_to_next_assistant` means provider/model-loop latency. - A huge gap after `assistant_text` with no following `tool_use`, `Stop`, or `idle` phase is a stuck provider/TUI turn, not tool latency or hosted ingest lag. On a Bedrock Claude flow, also check whether `LONGHOUSE_FORCE_NATIVE_CLAUDE_CHANNELS=1` is usi...