A Cyberpunk 2077 modding IDE built on VS Code. It takes WolvenKit's capabilities, the archive browser, the CR2W file editors, import and export, and project packing, and delivers them as VS Code extensions, with WolvenKit's own C# engine doing the file work behind a local bridge process.
.cpmodproj projects.REDnode is runtime scripting: a Node API that talks to the running game. REDcode is build-time tooling: files, archives and projects. They share the HUD house style, and the REDnode HUD VS Code theme is REDcode's default theme. The two are meant to work as one loop: a REDnode mod is edited in REDcode, deployed to the running REDnode process without restarting the game, and the game's events and logs stream back into REDcode. A redcode-rednode extension carries this: project scaffolding, generated types, a run task, a deploy command and a live event view.
REDcode and REDnode exist to offer a modding ecosystem that works with AI assistants as well as it works with people. The stack is chosen for that: JavaScript and TypeScript, Node and npm, HTML for every view, VS Code as the shell, and Claude as the first assistant it is built with. These choices shape the design more than feature parity with existing tools does.
Game files as CR2W JSON, tweaks as YAML, scripts as redscript and JavaScript, projects as folders. No state lives only inside a GUI. Whatever a person can see in REDcode, an assistant can read, and whatever a person can change, an assistant can change through the same files and calls.
The bridge's JSON-RPC methods serve the VS Code extensions and an MCP server alike. An assistant such as Claude Code can browse archives, convert files, query TweakDB, run scripts and pack a mod through the same calls, while REDcode stays the person's view of the same project.
Mod tooling, scripts and shared code are npm packages. The wkit-compatible scripting API ships as a typed package, so existing community scripts become packages and new ones get completion and documentation for free, for people and for assistants.
An assistant working in REDcode edits a REDnode mod, REDcode deploys it to the REDnode process attached to the running game, the change takes effect at once, and the game's events and logs stream back into REDcode. The assistant sees the result and iterates. Tier 2 mods reload freely because they run outside the game; Tier 1 interceptors swap between frames. Asset changes that the game cannot reload while running are marked as needing a restart.
The same process is debuggable live. REDnode's Tier 2 is an ordinary Node process, so VS Code's built-in debugger attaches to it: breakpoints, stepping and watches in the TypeScript source, and a Debug Console that evaluates calls such as await game.player.getHealth() against the running game. Tier 1 interceptors run in QuickJS inside the game, which has no inspector, so they get tracing and replay: inputs and outputs are recorded and the interceptor is re-run in Node under the debugger.
Every viewer is HTML, so it can be reused in the docs site, in previews an assistant produces, and in the branded fork. API references for the bridge, the scripting API and the game types are generated from source and RTTI, shared with REDnode's docs site, and readable by assistants as well as people.
Read from the WolvenKit repository at commit 4d1716b1 (2026-10-10, version 9.1.0). The split between headless libraries and the WPF application decides what REDcode can reuse.
| Project | Lines of C# | Target | Contents | Reusable by REDcode |
|---|---|---|---|---|
| WolvenKit.Core | 5,400 | net10.0 | Oodle compression, hashing, common services | Yes |
| WolvenKit.RED4 | 684,800 | net10.0 | CR2W reader and writer, every game type (mostly generated classes), archive format, TweakDB | Yes. This is the engine |
| WolvenKit.Common | 20,400 | net10.0 | JSON serializer for CR2W, DDS and texture conversion, services | Yes |
| WolvenKit.Modkit | 21,600 | net10.0 | Import and export: glTF meshes, textures, animations, Wwise audio, packing | Yes |
| WolvenKit.CLI | 1,200 | net10.0 | Command-line front end over the libraries above | Yes, as a reference for the bridge |
| WolvenKit.App | 88,600 | net10.0-windows | View models, project model, scripting host, document logic | Partly. Project model and scripting API are the useful parts. Tied to WPF view models |
| WolvenKit | 37,300 | net10.0-windows | WPF views built on Syncfusion controls, HelixToolkit 3D, AvalonEdit | No. WPF plus a commercial control suite |
kraken.dll: Oodle decompression. Has Windows, Linux and macOS code paths.texconv.dll, DirectXTexNet: texture conversion. Windows-only.wwtools.dll: Wwise audio.archive, unbundle, uncook, import, export, pack, build, convert, conflicts, hash, oodle, settings, wwise. convert turns CR2W files into JSON and back, and --print writes the JSON to stdout.
WolvenKit embeds V8 (ClearScript) and exposes a wkit API of about 44 functions to user scripts: load and save project files, get files from archives by path or hash, export, query TweakDB, hash strings, open documents. Five hooks: onSave, onExport, onPreImport, onImportFromJson, onParsingError.
WolvenKit already has a UI-independent, JSON-shaped API designed to be called from JavaScript. It is close to the contract REDcode's bridge needs, and the community has scripts written against it. The bridge should offer the same surface, so those scripts keep working. One caveat: that API lives in WolvenKit.App and reaches into WPF view models, so the bridge reimplements it over the headless libraries rather than referencing WolvenKit.App.
RedJsonSerializer writes { Header, Data: { RootChunk, EmbeddedFiles } }. Every editor in REDcode works on this shape..cpmodproj file next to source/archive, source/raw, source/resources and packed/. Per-project layout.xml stores WolvenKit's panel layout.ERedExtension, from mesh, xbm, ent and app to streamingsector, scene and inkwidget.| Option | What it is | Strengths | Weaknesses |
|---|---|---|---|
| A. Extension pack | REDcode is a set of extensions installed into stock VS Code. | No build infrastructure. Marketplace distribution and auto-updates. Fastest to ship. | No branding. Layout is a suggestion, not a default. The .NET bridge must be downloaded on first run. |
| B. Minimal fork | A Code - OSS build with a custom product.json: name, icon, default theme, bundled extensions, Open VSX as the extension registry. No changes to workbench source. This is the VSCodium pattern. | A branded REDcode application. The bridge, theme and layout ship in the installer. Upstream VS Code merges are trivial because nothing in the source changes. | Build, signing and release pipeline to run. Cannot use the Microsoft Marketplace, so every dependency (including Redscript IDE) must be on Open VSX or bundled. Monthly upstream rebases. |
| C. Deep fork | Modify the VS Code workbench itself. | Anything is possible. | Every upstream release becomes a merge. Not needed: everything in the feature map is reachable from the extension API. |
Build everything as extensions (A) and treat the branded fork (B) as a packaging step at the end. B is A plus a product.json and a build pipeline. Nothing in the extensions changes between the two, so the fork can wait until the extensions are worth shipping.
Microsoft's Marketplace terms limit its use to Microsoft's own products. Forks such as VSCodium and Cursor point at Open VSX instead. A REDcode fork would do the same, and the REDcode extensions would be published to both registries. The exact wording of the current terms was reported second-hand in research and should be read directly before the fork ships. Checked on 2026-10-11: the Redscript IDE extension (jac3km4.redscript-ide-vscode) is on the Marketplace only, not on Open VSX, so the fork must bundle it with its author's permission or depend on it being published there.
| Option | Approach | Strengths | Weaknesses |
|---|---|---|---|
| Port | Rewrite the parsers and tools in TypeScript. | Single language. No .NET runtime to ship. Could run anywhere VS Code runs. | 685,000 lines in RED4 alone, most of it generated type definitions that would need regenerating from the game's RTTI. Oodle, DirectXTex and Wwise are native and would need WebAssembly or native Node modules. Years of work before parity. Translating GPL source is a derivative work. |
| Wrap | Run WolvenKit's headless libraries in a separate .NET process. Extensions send requests and render the results. | All format support on day one, and it tracks WolvenKit's updates. The UI is the only thing to build, which is true in every option because the WPF layer is not reusable. | Ships a .NET runtime (about 80 to 100 MB self-contained). Windows-only until the native libraries are. WolvenKit has no stable public API, so the bridge pins a version. |
| Hybrid | Wrap for formats, port what is cheap and benefits from being native in VS Code. | This is what "wrap" becomes in practice. The project model, hashing, YAML and redscript editing, file watching and all UI live in TypeScript. CR2W, archives, Oodle, textures, meshes, audio and TweakDB stay in C#. | |
Whether REDcode ports or wraps, the UI is rebuilt. WolvenKit's views are WPF on a commercial control suite (Syncfusion) and a WPF 3D engine. None of that transfers to a web-based editor. The port-or-wrap question is only about the engine, and wrapping keeps 730,000 lines of working, maintained code.
| Method group | Examples | Backed by |
|---|---|---|
| archive | archive.list, archive.search, archive.extract, archive.conflicts | RED4 archive manager |
| cr2w | cr2w.toJson, cr2w.fromJson, cr2w.getChunk, cr2w.patch, cr2w.createInstance | CR2W reader and writer, RedJsonSerializer |
| convert | texture.toPng, mesh.toGltf, audio.toWav | Common (texconv), Modkit, wwtools |
| modkit | import.run, export.run, pack.run, build.run | Modkit |
| tweakdb | tweakdb.records, tweakdb.record, tweakdb.flats, tweakdb.query | TweakDB service |
| hash | hash.fnv1a64, hash.resolve | Core |
| script | script.run with the wkit API routed back over RPC | ClearScript V8 |
| mcp | The same methods exposed as an MCP server for assistants such as Claude Code | Bridge, shared with the extensions |
| progress | $/progress notifications and cancellation on every long call | vscode-jsonrpc |
cr2w.getChunk and sends edits as patches, rather than round-tripping whole documents.Every WolvenKit panel and document type, its VS Code counterpart, and a rough size. Sizes are relative: S days, M weeks, L a month or more, XL a quarter or more.
| WolvenKit | In REDcode | How | Size |
|---|---|---|---|
| Project Explorer | Tree view in the REDcode sidebar | TypeScript. Reads .cpmodproj and the source folders. File watcher for changes. | S |
| Asset Browser | Tree view with search, "add to project" and "open" actions | Lazy tree over archive.list and archive.search. | M |
| Properties | Side pane inside the CR2W editor, plus a Properties view in the secondary sidebar | Webview. Follows the selected chunk. | M |
| Log | Output channel "REDcode" | Bridge log messages forwarded. | S |
| Tweak Browser, LocKey Browser | Tree views with search | Over tweakdb.* and the localization lookups WolvenKit already exposes to scripts. | S |
| Import, Export | Commands, a settings webview and tasks | Over import.run and export.run. Progress in the status bar. | M |
| Hash tool | Command with quick pick | Over hash.*. | S |
| Audio player | Webview with an <audio> element | audio.toWav, then play from the cache. | S |
| (new) REDnode console | Live events and logs from the running REDnode process, deploy status | Over REDnode's development endpoint. Output channel plus a tree of recent events. | M |
| (new) REDnode debugger | Attach VS Code's debugger to the running REDnode process; Debug Console against the live game | Launch configuration over the Node inspector with source maps. Tier 1 interceptors: trace and replay in Node. | S attach, M replay |
| Home page | Walkthrough and welcome view | VS Code walkthrough contribution. Recent projects, new project, docs links. | S |
| WolvenKit | In REDcode | How | Size |
|---|---|---|---|
| RedDocument (CR2W chunk editor) | Custom editor: chunk tree, property grid, raw JSON tab | Webview over cr2w.getChunk and cr2w.patch. Undo and redo through the custom editor API. This is the core of REDcode and the largest single piece. | XL |
| RDTTexture (xbm, dds, cubemaps) | Image viewer with mip, channel and zoom controls | texture.toPng, webview. | M |
| RDTMesh (3D preview) | 3D viewer | mesh.toGltf, three.js in a webview. Material parity with WolvenKit's renderer is a later step. | M viewer, L materials |
| RDTInkTextureAtlas | Atlas viewer with slot overlay | PNG plus the atlas JSON. | S |
| RDTText, RDTData, JSON | Built-in text editor | Nothing to build. | S |
| TweakXLDocument (yaml, tweak) | Language support: syntax, completion from TweakDB, validation | Check for an existing community extension first. | M |
| WScriptDocument | Built-in JavaScript editor plus wkit typings and a Run command | script.run in the bridge, so existing community scripts work. | M |
| RDTGraph (quest, scene, behavior graphs) | Node graph editor | Webview with a graph library over the JSON. Each graph type has its own node set. | XL |
| RDTWidget (ink UI preview) | Widget renderer | Reimplements WolvenKit's ink layout in a webview. Defer. | XL |
| RDTLayeredPreview (mlsetup materials) | Material preview | Needs the 3D viewer with materials first. Defer. | L |
| redscript | Redscript IDE extension | Reused as a dependency of the pack. Not rebuilt. | S |
WolvenKit's default layout, from its DockStatesDefault.xml, and the closest VS Code arrangement. VS Code has fixed slots: a primary sidebar, a secondary sidebar, a bottom panel and the editor area. Views can be dragged between slots and VS Code remembers where they go.
| WolvenKit slot | VS Code slot | Note |
|---|---|---|
| Left: Project Explorer over Properties | Primary sidebar, REDcode view container | Same shape. |
| Top strip: Asset Browser | Secondary sidebar, top view | VS Code has no slot above the editors. The Asset Browser can also live as a tab in the bottom panel, which is closer to a wide strip. The user decides, VS Code remembers. |
| Right: Import, Export, auto-hidden Tweak and LocKey browsers | Secondary sidebar, collapsed views | Same shape. |
| Bottom: Log | Panel, Output channel | Same shape. |
Per-project layout.xml | Workspace state | VS Code stores view placement per workspace on its own. A "REDcode: Reset layout" command restores the default. |
These are the known constraints and the usual readings of them. Have someone qualified confirm before a public release, and talk to the WolvenKit team early. The modding community is small and a tool seen as a hostile clone would struggle.
kraken.dll (Oodle): WolvenKit redistributes it. Its origin and license need checking before REDcode redistributes it too.REDcode is RED for REDengine and code for VS Code, the editor it is built on. It was chosen on 2026-10-11 after checking three places. CD Projekt RED uses REDengine, REDmod, REDlauncher and REDcode, not REDcode. No Cyberpunk modding tool uses it. Outside modding, RED Digital Cinema's REDCODE RAW video codec and Core War's Redcode language share the spelling; both are different products in different fields and were accepted. A trademark search by someone qualified is still worth doing before the branded fork ships.
| Risk | Impact | Mitigation |
|---|---|---|
| UI effort underestimated | WolvenKit's UI is 126,000 lines of WPF and view models. The CR2W editor alone is months. | Ship the browse-extract-pack loop first. Add editors by what modders use most. |
| WolvenKit internal API churn | The bridge breaks on upstream updates. | Pin a WolvenKit version. Keep the bridge thin. Upstream patches that make the libraries easier to host benefit both projects. |
| Huge documents over JSON | Stalls and memory spikes on sectors and big meshes. | Lazy chunk reads and patches. Bulk data via files. |
| Windows-only natives | No Linux or macOS. | Accept for v1. Oodle already has non-Windows paths; texture conversion is the blocker. |
| Registry split | Fork users cannot install from the Microsoft Marketplace. | Publish REDcode extensions to Open VSX and the Marketplace. Bundle dependencies in the fork. |
| Upstream VS Code tracking | Fork falls behind. | No source changes, only product.json and bundled extensions. Rebase monthly in CI. |
| Community reception | Seen as a competitor to WolvenKit. | Position as a front end for WolvenKit's engine. Contribute bridge-friendly changes upstream. Credit prominently. |
| Name overlap outside modding | REDCODE RAW (a video codec) and Redcode (Core War) share the spelling. | Checked and accepted. Trademark search before the fork ships. See section 08. |
Name and license model: done (REDcode, split model with REDbridge under GPL-3.0). Redscript IDE on Open VSX: checked, it is not. Remaining: build WolvenKit's headless libraries locally and confirm Code - OSS builds on the reference machine. The WolvenKit team is contacted once a working proof of concept exists.
A .NET bridge with archive.list, cr2w.toJson, cr2w.fromJson, texture.toPng and hash.*. A VS Code extension that spawns it and offers "Open game file as JSON". Proves the data path end to end.
Open a .cpmodproj. Project Explorer, Asset Browser with search, add to project, extract, Log channel, status bar. REDcode becomes useful for browsing and extracting.
The CR2W custom editor with chunk tree, properties and patches. Texture viewer. TweakXL language support. Undo, redo, dirty state and save back to CR2W.
Import and export over Modkit with a settings webview. Pack and build tasks. First mod built start to finish inside REDcode. Publish the extension pack.
3D viewer over glTF. Audio player. Tweak and LocKey browsers. wkit-compatible script runner with typings, published as an npm package. MCP server over the bridge, so assistants can work a project alongside REDcode. REDnode integration: scaffold, generated types, deploy to the running REDnode process, events and logs streamed back, debugger attached with a live Debug Console, trace and replay for interceptors.
Graph editors for quest, scene and behavior files. Ink widget preview. Layered material preview. Ordered by what modders ask for.
Code - OSS build with product.json: REDcode name and icon, REDnode HUD theme as default, bundled extensions and bridge, Open VSX registry. Installer and release pipeline.