rail-debuggerlisted

# Rail Connector Debugger Move from symptom to evidence before changing configuration, processes, or repo files. Read [debugging-playbook.md](references/debugging-playbook.md) for exact checks. ## Diagnostic Layers 1. Codex tool exposure 2. MCP registration and process environment 3. installed Claude executable and capabilities 4. Windows broker or tmux ownership/lifecycle 5. Claude authentication, trust, and terminal state 6. session-log identity and transcript completion 7. caller workflow and concurrency Do not reinstall before identifying the failed layer. ## Core Rules - Treat diagnose, inspect, list, and report-only requests as non-mutating. Stop before installation, process termination, configuration, or file edits unless the user asked for a fix. - Enforce the same-OS contract. Native Windows Codex controls native Windows Claude; WSL is separate. - On Windows, the broker owns Claude Code ConPTY sessions across MCP task refreshes. Distinguish Claude Desktop processes, MCP stdio clients, broker, and Claude Code children. - If tools are missing after code/config changes, verify registration and use a fresh Codex task before diagnosing runtime behavior. - Prefer the platform installer or `codex mcp add` plus `codex mcp get` over direct configuration edits. If a fallback edit is unavoidable, back up `config.toml` first and parse it afterward. - Call `status` and `get_claude_capabilities`; do not infer permission or Ultracode support from stale docs.