Changelog / newest first

Release notes.

What changed in each CT Client release, from the current CT v4.3.0 back to the CT Loader foundations in v2.0.0.

Current CT v4.3.0 Requires JDK 21 or later Downloads release.html

CT v4.3.0 — download everything, or drop one jar

CT v4.3.0 answers the two questions the module platform left open: where is the download-everything button, and why did dropping a single module do nothing.

What changed

  • One-click full download. The release page now offers CT-Client-4.3.0-full.zip: CT-Main, all thirteen modules, launcher scripts, and a read-me, already configured. Unzip it, double-click Start CT-Main.command on macOS or Start CT-Main.bat on Windows, and the launcher starts with every feature. Nothing to install by hand.
  • Dropping one module now brings what it needs. Modules declare what they require. When an installed module needs another one that is missing, CT-Main downloads it from the official site automatically. Dropping only About used to install About and then skip it at load, because About requires Theme; now Theme is fetched too and the About view appears.
  • Drop targets that work on every desktop. Dragging onto a .jar depends on a Java file association that some systems no longer ship. The full download therefore includes Install modules.command (macOS and Linux) and Install modules.bat (Windows): drop module jars onto those files and they are installed, then CT-Main starts.
  • Install from inside the launcher. The Modules view has an Install module jar… button. Pick one or more jars, CT-Main installs them and offers to restart so the new modules load.
  • Missing modules are named. After an install that leaves requirements unmet, the window opens on the Modules view and the console lists each skipped module with its reason, the module id it needs, and the address to download it from.
  • Headless install for scripts. java -jar CT-Main-4.3.0.jar --install-modules <jars> installs and exits without opening a window; --no-fetch turns the automatic download off.

Verification

  • The full bundle was unzipped and started: all thirteen modules loaded from the bundled modules folder, and the launcher scripts kept their executable bit through the ZIP.
  • Dropping only the About jar on a clean folder fetched Theme from the site and reported Loaded 2 module(s), skipped 0 with the About view registered.
  • --install-modules installed a jar and exited without opening a window.
  • Every page was re-checked for links, structure, and version consistency.

Download the full package How installing works

CT v4.2.0 — drag modules onto CT-Main

CT v4.2.0 makes installing a module a drag away. Drop one or more module jars — or a folder holding them — onto CT-Main-4.2.0.jar and CT-Main installs everything it finds, then opens with the new features already loaded. No separate jar to run, no restart.

What changed

  • Drop onto CT-Main. Select several module jars and drop them on the main file: each one is copied into the modules folder CT-Main uses, and older jars of the same module are replaced. Dropping a folder installs every module jar inside it.
  • Installed before loading, so no restart. CT-Main installs the dropped modules before it scans the modules folder, so the features are in the window that opens straight away.
  • No duplicate windows. A running launcher records its process id and modules folder in ~/.ct-client/instance.lock. If one is already open on the same folder, the dropped copy installs the modules, prints what it did, and stops — telling you to close that window and start CT-Main again.
  • The report is always visible. In a terminal it is printed; when the drop happens in Finder or Explorer there is no console, so the same report appears in a window.
  • Running a module jar still works. The one-file install from v4.1.0 is unchanged, with --print, --remove, --launch, --no-gui, and --modules-dir.
  • Modules that need others say so. A dropped module whose requirements are missing is installed and reported as skipped at load time, with the missing module id.

Verification

  • Dropped jars, dropped folders, a missing path, a non-module jar, and an upgrade over an older build were all exercised; the replacement and the skip messages are covered by unit tests.
  • Dropping the 4.2.0 theme jar onto a folder holding the 4.0.0 build replaced it, and the window that opened listed theme 4.2.0.
  • The already-running path was verified against a live process holding the lock: the modules were installed and the second window stayed closed.

Download CT-Main v4.2.0 Module catalog

CT v4.1.0 — modules install themselves

CT v4.1.0 turns every feature module into a runnable file. The jars are unchanged inside — same ct.module.json manifest, same code — but each one now starts. Run a downloaded module jar once and it copies itself into the modules folder CT-Main reads, so the main program gains that feature on its next start. Nothing has to be moved by hand.

What changed

  • Every module jar is runnable. java -jar ct-module-theme-4.3.0.jar, or a double-click, installs the module. --print reports the target folder without writing, --remove uninstalls the module, --launch starts CT-Main right after the install.
  • CT-Main records the folder it reads. Every start writes the modules folder it actually used to ~/.ct-client/last-modules-dir, so a module downloaded anywhere lands in the same folder your launcher loads: next to CT-Main.jar, or ~/.ct-client/modules.
  • Upgrades replace the old jar. Installing a newer build of a module removes the older jar with the same module id, so the folder never holds two copies of one feature and never silently skips one as a duplicate.
  • The Modules view shows the detail. Module id, version, description, the modules folder path, and an open-folder button next to the website link.
  • New guide: build a runnable module. Build a runnable module walks through a module from an empty folder: the pom, ct.module.json, the entrypoint, the executable packaging, and the install into CT-Main.

Fixes carried in this release

  • The verification render draws every view on the CT background instead of white, and it now renders the Modules view as well.
  • The Modules view no longer paints a light background behind the module list.
  • A duplicate module id is reported with both jar names and what to do about it.
  • This changelog keeps the version each entry describes instead of showing the current version everywhere.

Download CT-Main v4.1.0 Build a module

CT v4.0.0 — the modular platform

CT v4.0.0 splits the launcher into a platform. The download is now CT-Main, a bare module host: starting it shows WELCOME TO MINECRAFT-CT and the link to the official website — nothing else. Every feature moved into a separate module jar that CT-Main loads from the modules folder at startup.

What changed

  • CT-Main ships bare. The main jar contains only the host: module scanning, dependency sorting, the service registry, the welcome window, and command dispatch. No installer, no accounts, no views.
  • 13 feature modules. Theme, rules, settings, console, installer, versions, launcher, offline profile, Microsoft account, mod manager, CT mod loader, command line, and about — each an independent jar with a ct.module.json manifest, downloadable one by one from the module page.
  • Dependency-ordered loading. A module loads only when every module it requires is present; anything else is skipped with a reason in the console. Modules publish services to each other through the host's service registry.
  • Command line becomes a module. java -jar CT-Main.jar ct --help — the ct command comes from the cli module; without it, CT-Main lists the commands it does have.
  • New Mod Manager module. A view over the game's mods folder: CT and Fabric mods recognized by their metadata, with open-folder and delete actions.
  • Everything is open source on the site. The complete source of CT-Main and all modules is browsable at code.html and available as one archive.

For existing users

  • The historical all-in-one ZIPs stay available on the release page, but they stop at v4.0.0; new work happens in the platform.
  • Settings, game directory, and installs are unchanged: ~/.ct-client/settings.properties and ~/.ct-client/game work exactly as before.
  • CT mods keep their format; the API package moved from com.ct.client.loader to com.ct.module.ctloader, so mod entrypoints importing CTMod update their import line.

Download CT-Main v4.0.0 Quick start

CT v3.0.0.1 — built-in Microsoft sign-in

CT v3.0.0.1 makes Microsoft sign-in work immediately. Pressing Sign in with Microsoft no longer requires an Azure application client ID: the launcher ships a built-in sign-in that opens the Microsoft account page and signs in with the Microsoft email and password. Nothing has to be configured first, and the offline profile remains one click away.

The classic client ID method from v2.x is kept as an option, and the user picks the method in the launcher settings. Both methods run the same OAuth 2.0 device code flow, the same Xbox Live, XSTS, and Minecraft services exchanges, and the same Java Edition ownership check before launch.

Sign-in methods

  • Microsoft account (built-in) — default. No requirements. CT requests a device code from the Live Connect endpoint at login.live.com, shows the code, opens microsoft.com/link, and the user signs in with the Microsoft account email. The client ID 00000000402b5328 is built into the launcher.
  • Custom Azure client ID — classic. For users who registered their own Azure application: a public client with the device code flow enabled and the XboxLive.signin and offline_access scopes. CT uses the stored microsoft.clientId or the CT_MICROSOFT_CLIENT_ID environment variable.

Settings and interface

  • The settings card adds a Microsoft sign-in selector above the Azure client ID (custom mode) field.
  • The method persists as the new microsoft.loginMode key in ~/.ct-client/settings.properties — builtIn by default, custom for the classic method.
  • The client ID field is enabled only while the custom method is selected, so switching back restores the stored value.
  • Version badge, window title, and the launcher version passed to the game all read 3.0.0.1.

Verification

  • The Live Connect device code endpoint was verified against the built-in client ID: it returns a real user code, and the token endpoint reports authorization_pending until the user signs in.
  • The window was rendered offscreen at the default size in both methods: the built-in selector disables the client ID field, the custom selector enables it.
  • All unit tests pass, including the new ClientSettingsLoginModeTest.

The release record, client profile, and license are in versions/CT v3.0.0.1/. Run ./mvnw package to build target/ct-client-3.0.0.1.jar and HTML/downloads/CT-Client-3.0.0.1.zip.

Download CT v3.0.0.1

CT v2.2.0.1 — dark theme interface refresh

CT v2.2.0.1 refreshes the desktop interface. The launcher window presents the CT dark theme with the brand palette: a branded header with the site icon and a version badge, grouped settings cards with labeled fields, custom-drawn buttons, rounded text fields, a custom version selector and memory steppers, checkboxes with accent glyphs, a slim animated progress bar, and a rounded console panel. Settings are arranged in two columns so launcher output stays visible at the default window size.

No launcher behavior changed in this release. Version selection, Microsoft sign-in, offline profiles, installation and verification, Fabric mod detection and profile routing, and game launching work exactly as in v2.0.0.1.

Interface

  • Header shows the CT brand icon, product name, v2.2.0.1 badge, account state, and sign-in actions.
  • Settings card groups Minecraft profile, memory, window size, directories, client ID, and JVM flags with uppercase caption labels.
  • Console card keeps the dark output log with the same 200,000-character history limit and auto-scroll.
  • Footer provides Install / Verify and Launch selected version actions above a status line with an animated progress indicator.

Verification

  • The window was rendered and inspected at the default size on macOS; all controls draw with the CT theme at the system look and feel.
  • Memory steppers step by 512 MB through the custom arrow buttons.
  • The version selector loads the full official manifest list (900+ IDs) and remains editable for typed version IDs.
  • Disabled, hover, focus, and busy states are drawn by the custom components; Launch stays disabled until an account is selected.

The release record, client profile, and license are in versions/CT v2.2.0.1/.

Download CT-Client-2.2.0.1.zip

CT v2.0.0.1 — Fabric mod detection and routing

CT v2.0.0.1 fixes Fabric mod launching. A Fabric JAR such as Sodium contains fabric.mod.json, not CT's ct.mod.json; CT's native loader cannot load it. The desktop client now detects Fabric mod JARs and automatically launches the sole installed Fabric Loader profile matching the selected Minecraft version.

If there is no matching Fabric profile, CT stops with instructions to install Fabric Loader into the same game directory. If multiple profiles match, select one explicitly. CT does not install Fabric Loader, Fabric API, Sodium, or other third-party mods. They remain subject to their own compatibility and license requirements.

Verification

  • Fabric mod detection checks JAR roots for fabric.mod.json.
  • Profile routing requires a Fabric Loader profile whose inheritsFrom matches the selected Minecraft version.
  • Existing Fabric launch behavior uses the profile's main class, arguments, and libraries; CT's native mod bootstrap is bypassed.
  • If there are no Fabric mods, vanilla and CT-native mod launch behavior remains unchanged.

The release record, client profile, and license are in versions/CT v2.0.0.1/.

CT mods and Fabric

CT v2.0.0 — CT Loader and the full version manifest

CT v2.0.0 reads the full Mojang version manifest and supports every listed Minecraft Java Edition version ID, including releases, snapshots, and legacy versions. The desktop UI defaults to Mojang's latest release, and CLI mode accepts any listed ID with --version or defaults to the latest release.

The official CT website is the release and download portal. The desktop product is CT Client; its CT-native mod format and API remain separate from Fabric, Forge, and NeoForge APIs.

What's included

  • CTLoaderBootstrap starts before the Minecraft main class and passes the original game arguments through.
  • CTModLoader scans <game directory>/mods for JAR files containing a root-level ct.mod.json.
  • Metadata schema version 1 includes an ID, name, version, entrypoint class names, and optional required mod IDs.
  • The loader rejects duplicate IDs, missing dependencies, dependency cycles, malformed metadata, and failing entrypoints.
  • CTMod and CTModContext provide an initialization entrypoint and mod-scoped logging.
  • The launcher's game classpath includes CT's application JAR so the bootstrap and mod API are available in the game process.
  • The desktop launcher scans installed version profiles, identifies Fabric, Forge, and NeoForge profiles, and launches their declared main class with inherited Minecraft metadata and installed loader libraries.
  • Legacy metadata using minecraftArguments, Maven-coordinate libraries, and implicit Java 8 runtimes is supported.
  • The official website lists and serves versioned desktop ZIP packages without requiring a GitHub release page.

Add a CT mod

Place the mod JAR in the configured Minecraft game directory's mods/ folder. For the default game directory, the path is ~/.ct-client/game/mods/. CT creates the directory on first launch. The JAR must contain a ct.mod.json file at its root.

Current boundaries

“All versions” means every version ID currently returned by Mojang's official manifest; a version with unavailable metadata or unsupported platform requirements cannot launch. CT does not install or update Fabric, Forge, or NeoForge; use each loader's own installer. A browser website can distribute CT but cannot install programs or launch local game processes. Mod JARs execute code with the user's permissions and are not sandboxed.

Mod guide