The engine host for REDcode, a Cyberpunk 2077 modding IDE built on VS Code.

REDbridge runs WolvenKit's headless C# libraries in a local process and exposes them over JSON-RPC: archive browsing, CR2W files as JSON and back, texture, mesh and audio conversion, TweakDB queries, import, export and packing. REDcode's extensions are its first client. AI assistants reach the same methods through REDcode's MCP server, redcode-mcp, which starts the bridge and talks to it over stdio as the extension does.

Read the docs · REDcode · REDnode

Note

Status: C1 bridge MVP works. The bridge indexes a game install, lists and searches archives, converts CR2W files to JSON and back byte for byte, decodes textures to PNG and resolves hashes, all over JSON-RPC on stdio. tools/probe.py exercises it against a real install in about seven seconds. Next: the REDcode extension that talks to it.

How it works

 VS Code (REDcode extensions)      REDbridge (.NET 10)                 WolvenKit libraries
 ┌───────────────────────────┐     ┌────────────────────────────┐     ┌────────────────────┐
 │ archive browser           │     │ JSON-RPC 2.0 over stdio    │     │ RED4: CR2W, archives│
 │ CR2W editor               │◄───►│ method groups: archive,    │◄───►│ Common: JSON, DDS   │
 │ import / export / pack    │     │ cr2w, convert, modkit,     │     │ Modkit: glTF, pack  │
 │ AI assistants via MCP     │     │ tweakdb, sound, hash       │     │ Core: Oodle, hashes │
 └───────────────────────────┘     └────────────────────────────┘     └────────────────────┘
                                    big outputs (PNG, glTF, WAV) go to a cache folder; RPC returns paths

Method group	Examples	Backed by
archive	archives, list, search, tree, extract, extractMany, openMod and extractFromMod (a mod's .archive anywhere on disk, no game needed)	WolvenKit.RED4
cr2w	toJson, fromJson, fileToJson; document sessions: open, getNode, getNodes, search, patch, save, close, documents, describeType, createInstance	WolvenKit.RED4, WolvenKit.Common
convert	texture.toPng, texture.fileToPng, texture.imageToPng (a plain TGA, DDS, TIFF, BMP, JPG or PNG to PNG, for viewing), mesh.toGltf, audio.toWav	WolvenKit.Common, WolvenKit.Modkit
mesh	info, infoMany: a mesh's or an entity template's bounds and appearance names, for an asset index	WolvenKit.RED4
sector	build: an EDGEbuilder scene into a streaming sector, a streaming block and an ArchiveXL file in a REDcode project	WolvenKit.RED4
project	pack (a folder into <modName>.archive through WolvenKit's packer, with warnings for paths with capital letters or spaces); export (a file under source/archive to the same path under source/raw: glTF, an image, WAV and so on) and import (back again, an existing texture keeping all its settings; a GLB over a template mesh for a new asset, 0.9.0), each listing the files written	WolvenKit.Modkit
modkit	build	WolvenKit.Modkit
tweakdb	types, records (by type, subtypes included, or path prefix, with chosen flats and LocKey text), record, flat, search, names (ids to paths, no load needed). Read offline from the game's tweakdb_ep1.bin, loaded on the first call in about 12 s	WolvenKit.RED4
sound	events: the sound event names WolvenKit knows, with their Wwise hashes, which name the event groups in sfx_container.opusinfo; importWavs: override game sound effects in a project from <hash>.wav files, writing the changed .opuspak files and a new index into its source/archive (0.9.0)	WolvenKit.Modkit's soundEvents.json, OpusInfo and opus-tools
loc	languages, search (by LocKey, secondary key or words in the texts), get (by LocKey or secondary key): the on-screen texts of the base game and Phantom Liberty, read offline, with a project's own onscreens files laid over them (the ones its .xl files name, and any under a language folder); projectFiles (those files for a language); newFile (an empty onscreens file for a project, named in an .xl)	WolvenKit.RED4
hash	fnv1a64, resolve	WolvenKit.Core
script	not planned: REDcode dropped its script runner

Mesh import

A GLB or glTF becomes a .mesh only over an existing one: WolvenKit's importer has no direct mesh import. For a new asset, project.import takes a template, a game path or a .mesh on disk, which it copies to the target first. A mesh already at the target is imported over as it is, so re-imports keep later changes. What a GLB import does to the mesh, from WolvenKit 9.1.0's MeshImportTools.ImportMesh (checked against the game's files, not yet in the game):

Part of the mesh	After the import
Geometry	From the GLB: one submesh per node with a mesh, sorted by node name, its first primitive. The GLB must have normals and tangents (Blender: export Tangents) and triangles; a node name with LOD_1, LOD_2, LOD_4 or LOD_8 sets its LOD
Bounds	Recomputed from the GLB
Material entries and the materials	The template's, unchanged. The GLB's materials are ignored, unless a .Material.json WolvenKit wrote lies beside it
Appearances	The template's names. Each one's chunkMaterials is sized to the new submesh count by the bridge, since WolvenKit leaves it as it was: a submesh keeps the material at its index, or the last one
Rig and bones	The template's bone set, grown from the GLB's skin when its joints carry rotations
Garment support	Rebuilt from the GLB when garment-support data is in it

The result's mesh field reports the submesh count, the GLB's material names per submesh (the materials for EDGEmat to make), the mesh's material entries, its appearances and what was resized. WolvenKit's own GLB exports name their materials Default.

Repository layout

Path	Contents
docs/	Documentation site
tools/brand/	Generates the banner, badges and icon
src/REDbridge/	The bridge: host, RPC surface, stderr logger
tools/probe.py	Stdlib Python client that runs every method over the real protocol
tools/wolvenkit-source.mjs	Fetches WolvenKit's source at the version the bridge uses into external/WolvenKit, for reading (npm run wolvenkit:source)

Build

git clone https://github.com/Edgemodders/REDbridge.git
cd REDbridge
npm run build:full                              # restore, then build
npm run probe -- "<Cyberpunk 2077 folder>"      # exercise every method against a game install

WolvenKit comes from its own NuGet packages (WolvenKit.Core, .RED4, .Common, .Modkit), at the version in WolvenKitVersion in src/REDbridge/REDbridge.csproj. Dependabot opens a pull request for each new WolvenKit release, the Build workflow checks that it compiles, and the probe is run against the game before it is merged. Later, npm run update pulls and rebuilds, and npm run build rebuilds after local changes. The scripts only wrap dotnet and git; package.json shows the exact commands. Needs the .NET 10 SDK, Node and Python 3. Details, including the per-user SDK route without administrator rights, are in the setup guide.

Roadmap

• C0 Decide. Build WolvenKit's headless libraries locally and confirm what the bridge references. Agree the approach with the WolvenKit team.
• C1 Bridge MVP. archive.list, cr2w.toJson, cr2w.fromJson, texture.toPng, hash.* over stdio. Proves the data path with REDcode.
• C2 to C4. Method groups for browsing, editing, import, export and packing, as REDcode's extensions need them.
• C5. Methods for REDcode's viewers: audio (sound.events, 0.7.2) TweakDB (tweakdb.*, 0.8.0) and LocKeys (loc.*, 0.10.0). No script host: REDcode dropped its script runner (agents and MCP tools cover it). The MCP server lives in REDcode as redcode-mcp, MIT, over stdio.

Phases follow the REDcode roadmap.

Compatibility goals

REDbridge pins a WolvenKit version and tracks its releases. Changes that make WolvenKit's libraries easier to host are sent upstream. Windows only for now, because WolvenKit's texture tooling is.

Legal

REDbridge links WolvenKit's libraries, which are GPL-3.0, so REDbridge is GPL-3.0. REDcode's extensions talk to it only over stdio and keep their own license. This repository contains no game files and no data extracted from them. Single-player modding only.

License

GPL-3.0