thjyneg/claude-code-rev

1. This is a terminal-first Claude Code client, not a web app. The runtime is TypeScript on Bun, with a custom Ink-based terminal UI under src/ink and React components under src/components to render the interactive experience.

2. The top-level application flow starts in src/main.tsx, src/bootstrap-entry.ts, and src/dev-entry.ts, then fans into the CLI entrypoints in src/entrypoints and the command registry in src/commands.ts. The CLI command tree in src/commands/** is the primary user-facing surface.

3. The core conversation engine lives around src/QueryEngine.ts, src/Task.ts, and src/Tool.ts. These files represent the central loop: user input becomes a task/query, the model responds, and tool calls are executed and folded back into the session state.

4. Tool execution is a major subsystem. Concrete tools live in src/tools/** such as Bash, file read/write/edit, web fetch/search, LSP, MCP, task management, and agent spawning. Shared orchestration and streaming happen in src/services/tools, which acts as the execution boundary between model output and side effects.

5. The UI is organized by concern rather than by screen. src/components/messages, src/components/permissions, src/components/tasks, src/components/PromptInput, and src/components/Settings are the main panes/dialog families. These render model turns, permission prompts, background activity, configuration, and status overlays.

6. State management is centralized in src/state, with app-wide state, selectors, and stores feeding both the UI and the tool/query loop. Supporting context providers in src/context and src/components/design-system make cross-cutting concerns like notifications, overlays, modal state, and theming available across the app.

7. Permissions and safety are first-class boundaries. src/hooks/toolPermission, src/utils/permissions, and src/components/permissions/** implement approval flows, rule matching, denial tracking, and mode selection. Tool handlers consult these layers before running potentially destructive shell, filesystem, or computer-use actions.

8. Session and multi-session coordination are split across several paths: src/assistant, src/history.ts, src/remote, src/bridge, src/server, src/ssh, and src/tasks. These modules cover resume/discovery, remote sessions, repl/bridge transport, direct-connect/server coordination, SSH-backed execution, and background task lifecycle.

9. Integrations with Anthropic, plugins, MCP, skills, and LSP are separate subsystems. Network/API access lives in src/services/api and src/services/oauth; plugin loading/validation in src/services/plugins and src/utils/plugins; MCP in src/services/mcp and src/components/mcp; skills in src/skills and src/services/skillSearch; language tooling in src/services/lsp and src/tools/LSPTool.

10. The repo also contains substantial platform-specific and degraded-mode compatibility code. The shims/ directory and src/native-ts, plus helpers under src/utils/computerUse, src/utils/claudeInChrome, and src/utils/teleport, stand in for native modules and private integrations that were not fully recoverable. This is important architecturally because some features are restored through fallbacks rather than original native binaries.

11. Persistent behavior is mostly file- and cache-based, not database-driven. Memory, settings, sessions, permissions, plugin metadata, and task output are stored through utilities in src/utils/* such as sessionStorage, settings, memdir, filePersistence, cachePaths, and secureStorage.

12. Telemetry, analytics, and operational safeguards are separate cross-cutting layers. src/services/analytics, src/utils/telemetry, src/services/internalLogging, and src/services/notifier capture usage, diagnostics, and events, while update, rate-limit, and sleep-prevention code keeps the CLI responsive and within policy.