f3f6c4c3b0
* refactor(app): move the bridge handlers out of main.ts createBridgeHandlers and the argv builders now live in app/electron/bridge-handlers.ts with no electron import, so a host other than Electron can run the same channel to argv mapping. main.ts keeps its default deps and re-exports, so the desktop app and its tests are unchanged. Two additive hooks for that host: scopeProjectFilter narrows the saved project filter before it becomes argv, and CODEBURN_NODE_BIN runs the bundled CLI with a named Node instead of Electron-as-Node. * feat(app): let the renderer run inside an editor The bridge can now say it is the VS Code host. When it does, the chord shortcuts and their hints step aside for the editor's own, Settings hands theme, language, default period and refresh to the editor's settings, the top bar shows a this workspace / all projects switch, and the editor can send a section, a period or a refresh to an open dashboard. formatResetTime moves to lib/format.ts so the status bar and the summary use the Plans wording. New strings are in all six locales. Nothing changes in the desktop app. * feat(app): build the renderer for VS Code webviews app/vite.vscode.config.ts builds two webview entries into vscode/dist/webview: the whole dashboard and the activity bar summary. renderer/vscode/bridge.ts implements window.codeburn over postMessage, forwarding only the channels in channels.ts; telemetry, update checks and the desktop companions are answered in the webview. localStorage is prefixed per scope so one workspace's cached views never paint in another's, and the theme follows the editor's light, dark and high contrast kinds through its --vscode-* tokens. * feat(vscode): CodeBurn extension for VS Code and its forks A status bar item with today's spend (~ when estimated) and a tooltip with the week, the month, this workspace, the top model and plan quotas; an activity bar summary; the desktop dashboard in an editor tab, scoped to the open workspace; eight commands and eight settings. The bundled CLI runs as the desktop's resident serve child through the shared client. Current VS Code, Cursor and Antigravity ship Node 24, so it runs on the editor's own Node; an older editor gets a system Node 22.13+ or a degraded run that says what it cannot read. A workspace folder maps to a rooted --project the way the CLI keys sessions, worktrees folding into their main repository. npm run package:vscode builds the .vsix. Unit tests cover the bridge host, status bar formatting, workspace mapping, settings and runtime choice; test:smoke drives a real VS Code against a fixture home. * ci, docs: build, test and package the VS Code extension A vscode job typechecks, unit tests, packages the .vsix, runs the smoke test in VS Code under xvfb and uploads the .vsix. docs/vscode.md covers the architecture, the measured editor runtimes and how to test. * fix(vscode): keep the currency setting out of workspace settings Changing codeburn.currency runs the CLI's own currency command, which every CodeBurn app shares, so a repository's .vscode/settings.json must not be able to set it: the setting is application scoped now. The smoke test also checks that the dashboard's renderer booted inside the webview and called the host, not only that its tab opened. * feat(vscode): version the extension 1.0.0, apart from the CLI The extension carried the CLI's 0.9.25. It now has its own version, 1.0.0. The host passes it to the webview, and the dashboard's nav footer, About dialog and Settings show it there instead of the renderer's package version; Settings adds "Bundled CLI 0.9.25" beneath it. The desktop app is unchanged. Nothing in the build or packaging writes the extension's version from the CLI. * fix(vscode): run the smoke test in Cursor, keep the demo shim out Cursor 3 opens its Agents window on a fresh profile, which starts no extension host, so the smoke run against Cursor.app hung; it now passes --classic for Cursor. The webview build no longer copies renderer/public/demo-shim.js, a browser demo harness, into the .vsix. * feat(vscode): a quiet star line in the summary, and a Star on GitHub command From the third day of use, the activity bar summary ends with the desktop's "Enjoying CodeBurn? Star us on GitHub" line, in the same six languages, with a close button. Clicking it or closing it hides it for good (kept in the extension's globalState). It is never a notification. The new "CodeBurn: Star on GitHub" command opens the repository page. No tracking parameters, no telemetry. * docs(vscode): marketplace screenshots in the README Five screenshots of the extension on real data (Overview in dark and light, the why it cost view, the status bar hover and the activity bar summary), 1600 px wide, each with a one-line caption. They live in vscode/media/screenshots, stay out of the .vsix, and the package script points vsce at the raw GitHub URLs on main. * fix(vscode): review fixes for settings trust, serve lifecycle and the tooltip - codeburn.provider and codeburn.quotaProviders are application scoped, like currency, so a repository's settings cannot turn quota requests back on, even in Restricted Mode. - deactivate removes the serve pid file once the child is stopped, and changing codeburn.nodePath restarts the serve child on the new Node. - codeburn.currency is applied at startup when the CLI's currency differs, not only when the setting changes. - The dashboard's Settings no longer shows per-plan quota switches in the editor, where the editor setting rewrites them on every boot; it points to the editor settings instead. - Workspace and model names are escaped in the status bar tooltip. - The README lists the dashboard actions that reach the network. - The staged CLI drops its dependencies' tests and TypeScript sources (466 files, 9.9 MB to 9.2 MB).
4.8 KiB
VS Code extension
The extension (codeburn.codeburn, source in vscode/) puts CodeBurn in VS Code and the editors built on it: a status bar item, an activity bar summary, and the desktop dashboard in an editor tab, scoped to the open workspace.
How it is built
Nothing is forked. The extension reuses three things the desktop app already has:
| Piece | Reused from | How |
|---|---|---|
| CLI client | app/electron/cli.ts |
The same resident codeburn serve --stdio child, watchdog, restart budget, idle retire and one-shot fallback. Bundled into the extension host. |
| Channel to argv mapping | app/electron/bridge-handlers.ts |
createBridgeHandlers, moved out of main.ts so it has no electron import. Same validators, same project filter, same daily optimize cache. |
| Dashboard | app/renderer |
Built a second time by app/vite.vscode.config.ts with two entries: renderer/vscode/dashboard.tsx (the whole App) and renderer/vscode/sidebar.tsx (the activity bar summary). |
The renderer talks to window.codeburn. In the webview that object is renderer/vscode/bridge.ts: every forwarded method becomes a postMessage to the extension host, which answers it with the shared handlers (vscode/src/host.ts). Only the channels in renderer/vscode/channels.ts are forwarded; the host refuses anything else. Telemetry, update checks and the desktop's tray and menu bar companions are answered inside the webview and never cross.
The webview's Content Security Policy allows scripts, styles, images and media only from the extension's own files (asWebviewUri). Boot data rides in a JSON block, so there is no inline script.
The bundled CLI lives in vscode/cli/, staged by vscode/scripts/stage-cli.mjs the same way app/scripts/stage-cli.mjs stages it for the desktop app, including the launch shim that corrects Commander's argv under Electron-as-Node.
Runtime
The CLI needs Node 22.13 or later, and node:sqlite (Node 22.5+) for Cursor, OpenCode and Copilot. Measured on 6 Oct 2026 with ELECTRON_RUN_AS_NODE=1:
| Editor | Version | Electron | Node | node:sqlite |
|---|---|---|---|---|
| VS Code | 1.140.0 | 43.7.3 | 24.21.0 | yes |
| Cursor | 3.23.12 (VS Code 1.128) | 42.10.0 | 24.18.1 | yes |
| Antigravity | 2.19.1 | 44.3.0 | 24.20.0 | yes |
So on current editors the CLI runs on the editor's own Node (process.execPath with ELECTRON_RUN_AS_NODE=1), exactly as the desktop app runs it on Electron. vscode/src/runtime.ts picks, in order:
codeburn.nodePath, if it is Node 22.13+ withnode:sqlite;- the editor's own Node, if it is;
- the first
nodeonPATHor in Homebrew, nvm, Volta, asdf or npm-global that is; - the editor's own Node anyway, with a one-time warning and a note in the summary and tooltip naming what it cannot read.
An older editor (VS Code before 1.101 ships Node 20) lands on step 3 or 4. The choice reaches the shared client through CODEBURN_NODE_BIN, which cli.ts uses instead of Electron-as-Node when it is set.
Workspace scope
A workspace folder maps to the project path the CLI files sessions under (src/parser.ts, resolveCanonicalProjectPath): the folder itself, or the main repository for a linked git worktree. Each folder becomes a rooted --project=<path> pattern, which matches that path and everything below it. The saved project filter's excludes still apply; its includes give way to the workspace. The dashboard keeps each scope's cached views apart by prefixing its localStorage keys with the scope.
Several windows
Every editor window has its own extension host and its own serve child. A window polls only while it is focused or its summary is visible, and its idle child retires after five minutes (the desktop keeps fifteen). Serve pid files are per host process, so a window never reaps another window's child, and a crashed window's child is reaped by the next one to start.
Building and testing
npm ci && (cd app && npm ci) && (cd vscode && npm ci)
npm run package:vscode # dist/, cli/, then vscode/codeburn-<version>.vsix
cd vscode && npm test # unit tests
cd vscode && npm run test:smoke # a real VS Code against a fixture home
test:smoke downloads VS Code stable (CI runs it under xvfb-run). On macOS, CODEBURN_SMOKE_APP="/Applications/Visual Studio Code.app" npm run test:smoke uses an installed editor instead, launched hidden as a separate instance. It checks activation, every command, the CLI's numbers through Copy Summary (all projects and the workspace scope against the CLI's own output), and the dashboard's scope switch.
Forks
The extension uses no proposed APIs and declares engines.vscode: ^1.82.0, so it installs in VS Code, Cursor, Windsurf, Antigravity and VSCodium, and can be published to Open VSX. Cursor and Antigravity were checked for their Node and node:sqlite above; Windsurf and VSCodium were not available to test.