# CodeLLDB: an LLDB debugger for VS Code's compiled-language workflows

> CodeLLDB wraps LLDB in a VS Code extension for C++, Rust and other compiled languages. It ships platform-specific binaries, a Python scripting layer and built-in visualizers, and its documentation is spread across a manual, a wiki and a changelog rather than one page.

**vadimcn/codelldb** — A VSCode debugger extension for native code, powered by LLDB.

- Repository: https://github.com/vadimcn/codelldb
- Website: https://marketplace.visualstudio.com/items?itemName=vadimcn.vscode-lldb
- Stars: 3,310 · Forks: 305
- Language: Rust
- License: MIT
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/vadimcn-codelldb

## What CodeLLDB replaces in a VS Code C++ or Rust setup

VS Code does not debug native code by itself. It talks to a debug adapter over the Debug Adapter Protocol, and something has to translate that protocol into calls the underlying debugger understands. CodeLLDB is that translator for LLDB. The package.json describes it as a "Debugger for native code, powered by LLDB" and the README states the primary focus is C++ and Rust, with built-in visualizers for vectors, strings, maps and other standard library types in those two languages.

The README also lists Ada, Fortran, Kotlin Native, Nim, Objective-C, Pascal, Swift and Zig as usable, with the caveat that the compiler must generate compatible debugging information. That caveat matters more than the list. CodeLLDB does not parse your language; it reads what the compiler emitted and asks LLDB to interpret it. If the debug info is poor, the debugger will look poor, and no extension setting fixes that.

The intended user is someone who already builds native code and wants breakpoints, stepping and variable inspection inside the editor. It is not a profiler, not a memory checker and not a build system. The README points to the LLDB tutorial and notes that all of LLDB's CLI commands and scripting features may be used in CodeLLDB, which is the honest description of its scope: it is an LLDB front end with a VS Code face.

## How the extension, the adapter and LLDB fit together

The repository layout shows the split clearly. There is an extension/ directory for the TypeScript side, an adapter/ directory, an lldb/ directory, a src/ directory holding a Rust workspace, and a bin/ directory. The Cargo.toml workspace lists members including src/adapter-protocol, src/codelldb-launch, src/codelldb-types, src/codelldb, src/lldb-stub and src/lldb. So the pieces are not one monolith: the VS Code extension is JavaScript, the adapter logic is Rust, and the LLDB binding is its own crate.

The adapter/ directory also contains scripts and lang_support, and pyproject.toml points pyright at adapter/scripts and adapter/lang_support with pythonVersion 3.6. That is where the Python scripting feature lives. The README lists "Python scripting" and "HTML rendering for advanced visualizations" as features, and the wiki link for data visualization is where the README sends readers for the C++ plotting example.

Data flow, as far as the repository shows it: VS Code sends DAP requests to the extension, the extension forwards them to the adapter, the adapter drives LLDB, and LLDB controls the debuggee. The debuggee/ directory, including debuggee/rust, holds test targets rather than anything you would ship. The practical consequence for a user is that a failure can sit at any of those layers, and the wiki has a troubleshooting page precisely because the boundary between extension, adapter and LLDB is where most confusion lands.

## Installing CodeLLDB and running a first session

The extension is published on the Visual Studio Marketplace under the identifier vadimcn.vscode-lldb, which the repository homepage points to. The package.json declares engines.vscode as ^1.61.0, so older VS Code builds are out of scope. Installation is the normal extension install path; the README does not describe a separate binary install step for end users, and the bin/ directory in the repository is part of how the packaged extension is assembled, not something the README asks you to populate by hand.

Once installed, the debugger is configured through a launch configuration. The README lists "Workspace-level defaults for launch configurations" as a feature, and the manual is the reference for the attributes. A minimal launch entry for a compiled binary looks like this:

```json
{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "lldb",
      "request": "launch",
      "name": "Debug",
      "program": "${workspaceFolder}/target/debug/myapp"
    }
  ]
}
```

The type must match the debugger identifier the extension contributes; the README and manual are where the exact attribute names are documented, and the manual is the authority if this snippet and the manual disagree. After starting the session, the README's feature list tells you what should be available in the UI: conditional breakpoints, function breakpoints, logpoints, hardware data access breakpoints (watchpoints), a disassembly view with instruction-level stepping, a memory view and a loaded modules view.

For embedded work, the README states that AArch64, ARM, AVR, MSP430, RISCV and X86 targets are supported and that you can debug on embedded platforms via remote debugging, linking to the remote debugging section of MANUAL.md. That section is where the connection details live; the README does not restate them.

## Where CodeLLDB stops being the right tool

The platform list is the first hard boundary. Hosts are Linux with glibc 2.18+ on x86_64, aarch64 or armhf, macOS 10.12+ on x86_64 and 11.0+ on arm64, and Windows 10 and 11 on x86_64. Anything else is unsupported by the README, and the Windows entry carries a pointer to a wiki page of Windows notes, which is a signal that Windows behaviour has enough caveats to need its own document.

Reverse debugging is the second boundary, and the README is explicit that it is experimental and requires a compatible backend. Experimental plus backend-dependent means you should not build a workflow around it without checking your target first.

Third, the extension is a VS Code extension. The repository is structured around the VS Code extension API, package.json declares activationEvents of onDebug, onUri and onStartupFinished, and the manual describes usage in that environment. People search for CodeLLDB in Neovim and in Zed, and the repository does not present those as supported paths. If your editor is not VS Code, treat any integration as something you have to verify yourself rather than something this project promises. That is a real limitation, not a footnote.

Finally, the documentation is distributed. The README says "For full details please see User's Manual" and points at MANUAL.md, the wiki, the LLDB tutorial and the discussions forum. There is no single page that answers everything, and the CHANGELOG is where release-level changes are recorded. Budget time for reading across those files.

## CodeLLDB against LLDB's own DAP server and against GDB-based adapters

The most direct alternative is LLDB's own DAP implementation, lldb-dap, which speaks the Debug Adapter Protocol directly from the LLDB side. The difference in approach is architectural: lldb-dap is part of LLDB and is driven by LLDB's own configuration surface, while CodeLLDB is a separate extension with its own adapter layer, its own launch configuration schema and its own visualizers. If you want the debugger to be whatever your LLDB installation already is, lldb-dap keeps you closer to upstream. If you want the editor-side features CodeLLDB advertises, such as workspace-level defaults for launch configurations, HTML rendering for visualizations and built-in C++ and Rust visualizers, those are CodeLLDB's own additions rather than LLDB features.

The other comparison is against GDB-based adapters, which is what people mean when they ask about codelldb vs gdb or codelldb vs cppdbg. The README's own framing is that CodeLLDB is powered by LLDB, and it points readers to the LLDB tutorial for the command set. So the choice is really LLDB versus GDB as the engine, with the extension riding on top. LLDB is the debugger of the LLVM project and pairs naturally with clang and with Rust's LLVM backend; GDB-based adapters are the older route for GCC toolchains. The README does not argue this comparison itself, and it does not claim CodeLLDB is better than a GDB adapter. It simply states what it is built on.

## Maintenance, licensing and what upgrades cost you

The repository is not archived, and the last push was on 2026-08-23. The most recent release listed is v1.12.3 on 2026-08-23, preceded by v1.12.2 on 2026-04-21 and v1.12.1 on 2025-12-31. That is a release cadence of a few versions a year, with a long gap between v1.12.1 and v1.12.2, so plan for occasional updates rather than a continuous stream. The CHANGELOG.md at the repository root is where those changes are described.

Upgrade cost is mostly about the launch configuration and the platform binaries. Because the extension bundles LLDB rather than using a system copy, moving to a new version can change debugger behaviour along with the extension. The wiki's troubleshooting page is the place the project points to when something breaks after an update. If you pin the extension version in a team setting, note that package.json declares engines.vscode as ^1.61.0, so the extension and the editor have their own compatibility floor.

The licence is MIT, declared in package.json and present as LICENSE at the repository root. MIT is permissive: it allows use, modification and redistribution with the licence and copyright notice retained. That is a description of the licence text, not legal advice, and the bundled LLDB components come from the LLVM project with their own licensing, which you should read if redistribution matters to you.

## Conclusion

Adopt CodeLLDB if you debug C++ or Rust inside VS Code and want LLDB's command set, Python scripting and the built-in standard-library visualizers without leaving the editor. Skip it if you need a debugger that works outside VS Code, since the repository is a VS Code extension and the manual describes the launch configuration in that context; nvim and Zed users should confirm their own integration path before committing. Before adopting, read MANUAL.md for the launch attributes, check the wiki's Windows notes if you are on Windows 10 or 11, and verify that your host matches the stated platform list: Linux with glibc 2.18+ on x86_64, aarch64 or armhf, macOS 10.12+ on x86_64 or 11.0+ on arm64, Windows 10 and 11 on x86_64.

## FAQ

### What is CodeLLDB?

CodeLLDB is a VS Code debugger extension for native code, powered by LLDB. The README states its primary focus is C++ and Rust, with built-in visualizers for vectors, strings, maps and other standard library types, and that it is usable with other compiled languages whose compiler generates compatible debugging information.

### How do I install CodeLLDB?

It is published on the Visual Studio Marketplace as vadimcn.vscode-lldb, which is the homepage listed in the repository, and package.json requires VS Code ^1.61.0. There is no separate end-user binary install described in the README; the bin/ directory is part of how the packaged extension is assembled.

### How do I use CodeLLDB in VS Code?

You add a launch configuration and start a debug session, then use the features the README lists: conditional breakpoints, function breakpoints, logpoints, watchpoints, disassembly stepping, a memory view and a loaded modules view. The README directs you to MANUAL.md for full details on the launch configuration attributes.

### What is the CodeLLDB platform package?

The repository ships platform-specific components under bin/ and lldb/, and the README lists separate host requirements per platform. The README does not use the phrase platform package or describe a separate package you install, so treat any such package as something to confirm against the marketplace listing rather than the README.

### Is CodeLLDB safe?

The repository is MIT licensed, not archived, and its last push was on 2026-08-23, with v1.12.3 released the same day. It wraps LLDB, so it runs with the same privileges as any debugger you attach to a process; the README does not make security claims beyond the licence and the platform list.

## Sources

- [License: MIT](https://github.com/vadimcn/codelldb/blob/master/LICENSE)
- [Project website](https://marketplace.visualstudio.com/items?itemName=vadimcn.vscode-lldb)
- [README](https://github.com/vadimcn/codelldb/blob/master/README.md)
- [Releases](https://github.com/vadimcn/codelldb/releases)
- [vadimcn/codelldb on GitHub](https://github.com/vadimcn/codelldb)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/vadimcn-codelldb