Claude Code first-launch initialization

Overview

This scenario traces the cold-start path from the claude CLI binary through fast-path dispatch, config/auth/settings loading, telemetry bootstrap, MCP discovery, and into the first interactive turn fn:main. The entry is the bootstrap shim that defers all heavy imports until after version and special-flag fast paths fn::program.

Steps

1. The process starts in the bootstrap shim which sets COREPACK_ENABLE_AUTO_PIN=0 and optional NODE_OPTIONS heap flags at module top-level before any dynamic import runs fn::program. It then calls main() with process.argv.slice(2) fn:main.
2. main() short-circuits on --version, then loads the startup profiler and marks cli_entry for later timing analysis fn:main fn:profileCheckpoint. Subsequent branches dispatch fast-paths like --daemon-worker, remote-control, daemon, ps/logs/attach/kill, and environment-runner before the normal Commander program is built fn:main.
3. For a normal launch, Commander's preAction runs enableConfigs() and kicks off managed-settings download, then the settings loader merges plugin base, user, project, local, flag, and policy sources into the session cache fn:loadSettingsFromDisk. Each source file is parsed and schema-validated with a per-file cache fn:parseSettingsFile fn:parseSettingsFileUncached.
4. Managed/MDM and HKCU layers are layered in, with the remote-managed layer consulted first for policy settings; a cache flush guards against poisoned merged reads from an earlier getSettings_DEPRECATED call fn:getSettingsForSourceUncached fn:getRemoteManagedSettingsSyncFromCache. Settings env vars are then applied into process.env so downstream code sees user-configured variables fn:applyConfigEnvironmentVariables.
5. Auth is resolved: if CLAUDE_CODE_OAUTH_REFRESH_TOKEN is present the refresh token is exchanged and persisted via installOAuthTokens, otherwise the stored OAuth tokens or API key source are used; subscription type is derived from those stored tokens fn:authLogin fn:installOAuthTokens fn:getSubscriptionType.
6. Telemetry is initialized: bootstrapTelemetry copies ANT_OTEL_* vars to their OTEL_* counterparts and defaults metrics temporality to delta fn:bootstrapTelemetry. initializeTelemetry then strips console exporters when stdout is the SDK channel, builds resource attributes via getPlatform, and constructs meter/logger/tracer providers registered through state setters fn:initializeTelemetry fn:getPlatform fn:setMeterProvider fn:setLoggerProvider fn:setTracerProvider fn:setEventLogger.
7. Telemetry readers are selected: getOtlpReaders/getOtlpLogExporters/getOtlpTraceExporters parse exporter types and protocols; BigQuery metrics are additionally enabled for 1P API, C4E, and Team users fn:getOtlpReaders fn:parseExporterTypes fn:isBigQueryMetricsEnabled fn:is1PApiCustomer. A shutdown hook is registered so providers flush on exit fn:registerCleanup.
8. MCP server discovery reads project/user/local/enterprise scopes, walking parent directories for .mcp.json project configs fn:getMcpConfigsByScope. Each configured server may have a headersHelper that is gated on trust-dialog acceptance before being invoked fn:getMcpHeadersFromHelper.
9. Workspace trust is resolved via TrustDialog, which inspects MCP servers, hooks, bash permission sources, apiKeyHelper, OTEL headers helper, and dangerous env var sources to decide whether to prompt fn:TrustDialog. Policy limits are also fetched and cached for gating features like remote control fn:fetchAndLoadPolicyLimits.
10. In headless/print mode, runHeadless subscribes to settings changes, initializes sandbox, loads initial messages, and dispatches to runHeadlessStreaming which registers a SIGINT handler and drains the command queue fn:runHeadless fn:loadInitialMessages fn:runHeadlessStreaming. The SDK initialize control request is answered with commands, agents, models, and account info before the first prompt is accepted fn:handleInitializeRequest.
11. The first turn's run() awaits deferred plugin install, refreshes plugin state, assembles MCP clients from app state plus SDK and dynamic clients, and calls drainCommandQueue which forwards the prompt to QueryEngine.submitMessage for the first interactive response fn:run fn:drainCommandQueue fn:submitMessage.

State touched

• state:sessionSettingsCache
• state:perSourceCache
• state:parseFileCache
• state:mdmCache
• state:hkcuCache
• state:pluginSettingsBase
• state:sessionCache
• state:sink
• state:eventQueue
• state:cleanupFunctions
• state:project

Decisions

(none in whitelist) fn:main