redscript is the compiler, decompiler and formatter for Cyberpunk 2077 mod scripts

What the language is and who it is for

REDscript is a statically-typed, object-oriented programming language designed for developing scripts for the REDengine, CD Projekt's game engine used in Cyberpunk 2077.

The language wiki is at wiki.redmodding.org/redscript, and the README points there for anyone who wants to learn the language itself.

So this is a scripting language for a shipped commercial game, which is a fairly specific thing to build a toolchain for. The script layer of a modern game engine is usually a scripting language with a scripting API bound to game systems, and mods hook into it. A toolchain for that language is what modding communities need, and redscript is the reference implementation of one.

The project is written in Rust, licensed MIT, and the last push to the repository was on 2026-06-09. The default branch is 1.0.x, and the listed releases are v1.0.0-preview.22 from 2025-09-07, v1.0.0-preview.21 from 2025-08-31 and v1.0.0-preview.20 from 2025-08-31.

So the versioning tells its own story. The project is on a preview line rather than a stable one, and the last three tagged builds are from a single week in August and September 2025. The source has moved since, but the published artefacts are a year old relative to the last commit.

Installing on Windows, and where the log file goes

Installation on Windows is the simplest of the two platforms, because the game compiles scripts on startup.

Download the `redscript-v{version}-windows.zip` archive from the latest release, and extract it into the main `Cyberpunk 2077` directory. When you start the game, successful setup can be confirmed with logs appearing in `Cyberpunk 2077/r6/logs/redscript_rCURRENT.log`.

The log file detail is worth keeping. A silent failure to compile leaves you with mods that do nothing and no obvious cause, so the path to the log is the first thing to check when a script does not take effect.

The macOS path has an extra step, because the game currently does not compile scripts on startup there. You download the `redscript-v{version}-macos.zip` archive and extract it into the main Cyberpunk 2077 directory.

  unzip ~/Downloads/redscript-v*-macos.zip -d "/Applications/Cyberpunk 2077"

Then there is the quarantine problem, which is a macOS behaviour rather than a redscript one. macOS automatically quarantines binaries downloaded from the internet, so you have to remove them from the quarantine manually.

  xattr -r -d com.apple.quarantine "/Applications/Cyberpunk 2077/engine/tools"

And because the game does not compile on startup on macOS, you start the game through the bundled script instead.

  "/Applications/Cyberpunk 2077/launch_modded.sh"

The path in that command, engine/tools, is where the compiler binary lives inside the installation.

The crate layout, which is the architecture

The project structure section lists the modular Rust crates in the crates directory, and the list reads as a compiler pipeline.

The cli crate exposes a command-line interface serving as the entry point for all tools in the project.

The compiler is split in three. compiler/frontend performs static analysis on REDscript syntax and lowers it to an intermediate representation. compiler/backend generates bytecode from that intermediate representation and handles monomorphization for generic functions and types. compiler/api provides a high-level API for interacting with the compiler.

Then decompiler, which decompiles bytecode back into REDscript source code, and io, which reads and writes binary files in the native REDengine format.

The syntax side has three crates: syntax/ast defines the Abstract Syntax Tree, syntax/parser parses REDscript source into the AST, and syntax/formatter formats REDscript source according to configuration. dotfile parses the configuration `.redscript` file.

Then there are the three scc crates, and this is the part with a specific purpose. scc/cli exposes a CLI that acts as a drop-in replacement for the original compiler made by CD Projekt. scc/capi exposes a C API with an interface similar to the scc CLI but with some additional capabilities like source mapping. scc/shared contains the common code used across the scc C API and CLI.

So there are two deliverables in one workspace: the native redscript toolchain, and a compatibility layer that lets existing modding workflows keep calling scc as they always have. The Cargo.toml workspace lists fifteen members including scc/core and a code-edit crate, and the workspace package version is 1.0.0-preview.22 on edition 2024.

The dependencies, and what they reveal about the implementation

The workspace dependency list is long and specific, and it tells you how the toolchain is built.

The parsing side uses chumsky at version 1.0.0-alpha.7 with the label feature, which is a parser combinator library. An alpha dependency in a compiler frontend is worth noting, since parser behaviour changes between alpha releases and a redscript release can therefore pick up a different parse without a version bump of its own.

The AST and container types use indexmap and hashbrown, which preserve insertion order, which matters for a compiler that must emit deterministic output so that recompiling unchanged source produces identical bytecode.

For diagnostics and reporting there is thiserror for error types, anyhow for application-level errors, and miette at version 3, which is the modern Rust diagnostic rendering library. Logging is flexi_logger with fern. The command line parsing uses argh, a smaller alternative to clap.

The bytecode side has crc32fast for checksums and pretty_dtoa for float formatting, and the io side uses ignore, vmap, file-id and tfd for file discovery and mapping, which is how it walks a project directory and decides which files to compile.

Two entries are about the native side. bindgen generates the FFI bindings, and mimalloc is the allocator, pulled in with the v3 feature. The presence of bindgen alongside the scc C API crates is the reason the C interface exists at all, and mimalloc is the kind of dependency a tool that allocates heavily in a loop reaches for.

Editor tooling, and the separate IDE repository

REDscript provides extensive editor tooling, including a language server and a debugger that integrate with many popular editors such as VSCode, neovim, IntelliJ IDEA, Zed, and Helix. For detailed setup instructions, the README points at the REDscript IDE repository at github.com/jac3km4/redscript-ide.

The separation is worth noting. The language server and the debugger are not in this repository, they live in a companion project, and this one is the toolchain: the parser, the compiler, the decompiler, the formatter and the io layer.

That division is the right shape for a language, because the editor side has to track the compiler's understanding of the language and the toolchain side has to stay usable as a standalone binary that mods can call at build time.

The list of editors is also a signal about how actively the language is used. VSCode, neovim, IntelliJ IDEA, Zed and Helix cover the range from the most mainstream editor to the newest terminal-first ones, and a modding community adopting all of them is a community with more than a handful of serious scripters in it.

The formatter deserves a mention too, because it is the feature that gets used most. syntax/formatter formats REDscript source according to configuration, and dotfile parses the configuration `.redscript` file, so formatting rules are per-project and readable rather than baked into the tool.

Where redscript is the wrong choice

Four cases argue against it.

The first is if you are not modding Cyberpunk 2077. The toolchain is specific to REDscript and to the REDengine's binary formats, and the io crate exists to read and write those formats. Nothing here generalises to another game's script layer.

The second is if you need a stable release. The version is a preview, the last tagged builds are from August and September 2025, and the source has moved on since. For a modding tool that runs at game startup, a change in behaviour between what you tested and what a user downloads is a real support burden, and the preview naming is the project's own signal that this is not settled.

The third is if you want to write scripts and nothing else. The repository gives you a compiler, a decompiler and a formatter, which is the right set if you are building tooling or reverse engineering existing scripts. If you only want to write a mod, the language wiki and a working editor setup are what you need, and this is a dependency rather than a destination.

The alternative in the same direction is the original scc compiler that ships with the game, or an existing modding framework that already wraps REDscript for a specific purpose. The difference in approach is that redscript is a from-scratch Rust reimplementation with a decompiler, a formatter and a source-mapping capable C API, where the original scc is a closed binary with none of those. If you need to decompile shipped scripts to see what a mod is really doing, or you need to integrate into a build pipeline with source maps, redscript is the tool. If you only need to compile a folder of scripts into the game, the bundled compiler is one less moving part.

Editorial conclusion

redscript fits a Cyberpunk 2077 modder who wants to compile scripts on game startup and who wants a decompiler and formatter alongside the compiler, since all three ship from one Rust workspace. It does not fit anyone writing mods for a different game or expecting a stable release, since the version is a preview and the tagged builds stop at v1.0.0-preview.22 from 2025-09-07. Extract the release archive into the Cyberpunk 2077 directory on Windows, remove the macOS quarantine attribute before running the bundled launcher, and read the language wiki at wiki.redmodding.org/redscript before writing anything.

Frequently asked questions

Official sources

1. Issues
2. jac3km4/redscript on GitHub
3. License: MIT
4. README
5. Releases