Architecture.

1. 1
   Fetch the manifest. Fetch version_manifest_v2.json, expose all listed version IDs in the UI, and resolve the requested ID only against that official catalog.
2. 2
   Verify version metadata. Fetch the version metadata and verify its SHA-1 against the manifest. A verified local copy is reused when it still matches.
3. 3
   Download and verify content. Download the client jar, every library whose rules match the current platform, the asset index, and each asset object. Every file is checked against the published SHA-1 and size; a mismatched download is discarded and never installed. Transfers use HTTP/1.1, because the asset CDN resets concurrent HTTP/2 streams, and transient failures are retried with backoff. A partial download is written to a .part file and moved into place only after it verifies, so an interrupted install never leaves a corrupt file behind.
4. 4
   Download the log configuration. Download the official log4j configuration referenced by the version metadata.
5. 5
   Prepare natives. Create the natives directory, including the per-library extraction subdirectories that the version metadata references.
6. 6
   Install the Java runtime. Resolve and install the Java runtime the version declares. Legacy metadata without a Java component uses the Java 8 legacy runtime. Runtime manifests are verified by SHA-1, executable bits are applied after download, symbolic links are validated against the runtime root, and a completion marker (.ct-runtime-complete) is written only after the whole runtime is verified.

Only HTTPS sources are accepted, and paths from official metadata are rejected when they escape their target directory. Platform-matched native classifiers are downloaded separately from classpath artifacts and safely extracted, honoring metadata exclusion paths so archive paths cannot escape the destination.

1. 1
   Build the placeholder map. Build it from the account, the installation, and the user's settings. Append the CT application to the game classpath for CT-native launches; external loader profiles use their declared game and loader libraries.
2. 2
   Evaluate default-user-jvm. Obtain Mojang's recommended memory and garbage collector flags, replacing the heap bounds with the user's configured values.
3. 3
   Evaluate version arguments. Apply OS rules and feature rules to modern arguments.jvm and arguments.game. For legacy metadata, tokenize minecraftArguments. Substitute supported placeholders and generate a classpath when older version metadata does not define one.
4. 4
   Choose the entrypoint. If a Fabric mod JAR with root-level fabric.mod.json is present and exactly one Fabric profile matches the selected Minecraft version, use that profile. For a CT-native launch, start CTLoaderBootstrap, which scans <game directory>/mods, validates each ct.mod.json, checks dependencies, initializes CT entrypoints in dependency order, then invokes Minecraft's official main class. For an installed Fabric, Forge, or NeoForge profile, start the profile's declared main class directly and let that loader handle its own mods.
5. 5
   Start the process. Start it with ProcessBuilder and an explicit working directory. No shell is involved, so no argument is re-parsed or expanded.
6. 6
   Stream output. Stream stdout and stderr to <game directory>/logs/ct-client-launch.log and to the CT output. The access token is redacted from any command echoed to the interface.

CT's own mod API supports Java entrypoints and logging only; it does not transform Minecraft classes or provide Minecraft lifecycle hooks. External loader profiles are launchable but must be installed separately. All mod JARs execute code with the user's permissions and are not sandboxed by CT. Authentication uses the OAuth 2.0 device code flow with the XboxLive.signin and offline_access scopes; access tokens are held in memory for the current session only and never written to settings.properties, the launcher log, or the command echo.

The ~/.ct-client directory tree

~/.ct-client/
  settings.properties          Non-secret launcher settings
  game/
    versions/<id>/<id>.json    Verified official version metadata
    versions/<id>/<id>.jar     Verified client jar
    versions/<id>/natives/     Natives subdirectories referenced by the metadata
    libraries/                 Rule-matched libraries, including natives classifiers
    assets/indexes/            Asset index
    assets/objects/            Asset objects, stored under their SHA-1 prefix
    assets/log_configs/        Official log4j configuration
    runtimes/                  Official Java runtime, with the completion marker
    logs/ct-client-launch.log  Streamed game output, appended per launch

JDK 21 or later is required. The Maven wrapper downloads Maven 3.9.16 on first use:

./mvnw package
java -jar ct-main/target/CT-Main-4.3.0.jar

The multi-module build produces ct-main/target/CT-Main-4.3.0.jar — the bare host with only Gson shaded in — plus one jar per module in ct-module-*/target/. The ctloader module jar shades Gson as well, because it runs inside the game process with only itself on the classpath. Publish the HTML/ directory to the official website to make the jars, the source archive, and the browsable source tree available.