CodeVetter · Repo Unpack · System map
microsoft/vscode
The system is a multi-process Electron application with parallel web and server builds. src/main.ts is the Electron main entry that reads argv.json, configures sandboxing and privileged schemes, then loads src/vs/code/electron-main/main.ts, which manually assembles a DI ServiceCollection, claims a single-instance IPC socket, and hands off to CodeApplication. The renderer boots the workbench through import-barrel entrypoints (workbench.desktop.main.ts / workbench.web.main.ts / workbench.common.main.ts) that register singleton services and contributions. Auxiliary processes — shared process, pty host, extension hosts, agent host — are spawned as Electron utility processes or Node forks and communicate over named IPC channels. A separate Rust crate under cli/ implements the `code` command-line launcher, tunnel daemon, and web server host, while src/vs/server and remote/ implement the remote extension host agent (vscode-reh).
- src/main.ts is the real Electron main entry: it configures portable mode, parses CLI args, reads/creates argv.json, toggles the Chromium sandbox, registers the privileged schemes vscode-webview/vscode-file/vscode-remote-resource/vscode-managed-remote-resource, and on app 'ready' calls bootstrapESM() then imports ./vs/code/electron-main/main.js.
- CodeMain.startup() in src/vs/code/electron-main/main.ts builds a ServiceCollection by hand (EnvironmentMainService, LoggerMainService, FileService+DiskFileSystemProvider, UriIdentityService, StateService, UserDataProfilesMainService, policy services, ConfigurationService) and wraps it in an InstantiationService before creating CodeApplication.
- Single-instance behavior is enforced by claimInstance(): the first process serves a node IPC socket at environmentMainService.mainIPCHandle (exported to child processes as VSCODE_IPC_HOOK) and writes a pid lockfile; a second instance forwards args to the running one and quits.
- CodeApplication.startup() creates an ElectronIPCServer, resolves machineId/sqmId/devDeviceId, spawns the SharedProcess via a MessagePortClient, installs ErrorTelemetry, lazily starts the AgentHostProcessManager, then calls initChannels() which registers roughly 30 channels (storage, policy, nativeManagedSettings, fileManagedSettings, local file system, userDataProfiles, update, encryption, nativeHost, webview, workspaces, menubar, url, localPty, externalTerminal, sandboxHelper, mcpGateway, extensionHostStarter, utilityProcessWorker, …) on both the renderer server and the shared-process client.
- The workbench ships three parallel entrypoint barrels: workbench.common.main.ts holds shared imports/singletons, workbench.web.main.ts adds web-only services and contribs, and workbench.desktop.main.ts layers desktop-only ones; comments in workbench.ts explicitly forbid registering services locally and direct authors to registerSingleton().
- Architectural layering base→platform→editor→workbench is machine-enforced: 'npm run valid-layers-check' invokes build/checker/layersChecker.ts, and 'npm run check-cyclic-dependencies' runs build/lib/checkCyclicDependencies.ts over out/.
- Process model: main process (electron-main), one renderer per window, a shared process for cross-window work (sharedProcessMain.ts), a pty host for terminals (ptyHostMain.ts/PtyService), extension hosts (local process, web worker, or remote), and an agent host utility process managed by AgentHostProcessManager/ElectronAgentHostStarter.
- A remote-server variant lives in src/vs/server (server.main.ts, serverServices.ts, remoteExtensionHostAgentServer.ts) packaged as vscode-reh via remote/package.json, and web serving is driven by the Rust CLI's serve_web command.
- The Rust CLI crate 'code' (cli/Cargo.toml, cli/src/bin/code/main.rs) parses args with clap, distinguishes integrated vs standalone mode, and dispatches subcommands including tunnel, serve-web, update, and a family of agent_* commands (agent_host, agent_ps, agent_kill, agent_logs, agent_relay, agent_stop, agent_endpoints).
- src/vs/sessions is a separate workbench layer ('agent sessions window') with its own entry barrels (sessions.desktop.main.ts, sessions.web.main.ts) that may import from vs/workbench but not vice versa, per the documented layering rules.
- product.json is the branding/config manifest (nameShort 'Code - OSS', dataFolderName '.vscode-oss', urlProtocol 'code-oss', win32/darwin ids, builtInExtensions list with sha256 pins); build commands are npm scripts wrapping gulp (npm run compile → gulp compile via gulpfile.mjs; npm run watch; npm run typecheck-client).
- Runtime boundaries are bridged by a channel abstraction: ProxyChannel/IPCServer in src/vs/base/parts/ipc, validatedIpcMain for renderer→main calls, and getDelayedChannel(ProxyChannel.toService(...)) used to lazily expose shared-process services like diagnostics and telemetryAppender as local DI services.