Configuration / CT v4.3.0

Settings and configuration.

Every non-secret setting lives in ~/.ct-client/settings.properties. Missing keys fall back to defaults, invalid numbers fall back per key, and access tokens are never written to disk — a Microsoft sign-in lasts for the current launcher session.

01 / Properties file

settings.properties.

A standard Java properties file created automatically when the launcher starts, holding every non-secret setting. Credentials and access tokens are never part of it.

KeyDefaultMeaning
microsoft.loginModebuiltInMicrosoft sign-in method. builtIn uses the built-in sign-in; custom uses the Azure client ID.
microsoft.clientIdemptyAzure public client ID for the custom sign-in method.
memory.minimumMb2048Minimum heap.
memory.maximumMb4096Maximum heap.
resolution.customfalseEnables the custom window size.
resolution.width854Window width.
resolution.height480Window height.
offline.playerNameemptyLast used offline name.
java.executableemptyJava executable override. Empty means the installed official runtime.
jvm.recommendedFlagstrueApplies Mojang's default-user-jvm entries.
game.directory~/.ct-client/gameGame directory.
  • Missing keys fall back to defaults. A key that is absent from the file behaves exactly as if it held its default value.
  • Invalid numbers fall back per key. A non-numeric or out-of-range number invalidates only the key it belongs to — the rest of the file still applies, and the memory or resolution values fall back to LaunchOptions.defaults().
  • Reading and writing. The settings module's SettingsStore creates the application directory and the file when missing and throws IOException when the file cannot be read. Modules reach it through the SettingsAccess service — see the API reference for the full member table.

The file lives alongside the game directory, which defaults to ~/.ct-client/game — the same layout described in architecture and used by the command line.

02 / Microsoft

Microsoft sign-in.

Online play requires a Microsoft account that owns Minecraft Java Edition. Two sign-in methods are available, and the built-in one is the default.

  • Microsoft account (built-in). The default. No Azure application and no setup — pressing Sign in with Microsoft requests a device code from the Live Connect endpoint at login.live.com, then the user signs in with the Microsoft email and password at microsoft.com/link. MicrosoftAuthenticator.signInDirect(status) runs this method.
  • Custom Azure client ID. The classic method, for users who registered their own Azure application. MicrosoftAuthenticator.signIn(clientId, status) runs it over the Microsoft consumers tenant, and the client ID is persisted as microsoft.clientId.
  • Public client, device code flow. A custom Azure application must be of type public client with the device code flow enabled, reporting the user code and verification address as it polls, and must be allowed to use the XboxLive.signin and offline_access scopes.
  • Method selection. Choose the method in the launcher's Settings panel; it is persisted as microsoft.loginMode with the values builtIn and custom. The client ID field is enabled only while the custom method is selected.
  • Environment override. The CT_MICROSOFT_CLIENT_ID environment variable overrides the stored client ID when it is set and not blank.
  • Desktop only. Microsoft sign-in is only available in the desktop launcher — command line mode always uses an offline profile.

If the custom method is selected without a client ID, the launcher reports Enter an Azure application client ID, or switch to the built-in Microsoft sign-in. The full sign-in exchange, the XSTS error mapping, and the d= prefix rule are described in accounts; token handling in security.

03 / Memory and window

LaunchOptions.

The LaunchOptions record carries every memory, resolution, and flag setting. Invalid arguments throw IllegalArgumentException from the record constructor.

LaunchOptions options = new LaunchOptions(2048, 4096, false, 854, 480, false, true, "release");
FieldMeaning
minimumMemoryMb, maximumMemoryMbHeap bounds, between MINIMUM_MEMORY_MB (1024) and MAXIMUM_MEMORY_MB (65536). The maximum must be at least the minimum.
customResolution, width, heightWhen enabled, the resolution must be at least 320 by 240, and the has_custom_resolution feature is reported to the game.
demoModeReports is_demo_user to the game.
recommendedJvmFlagsApplies Mojang's default-user-jvm entries before the version arguments.
versionTypeValue of version_type. "release" for a normal install.
  • Bounds. MINIMUM_MEMORY_MB is 1024 and MAXIMUM_MEMORY_MB is 65536. A maximum below the minimum is rejected with IllegalArgumentException.
  • Resolution floor. A custom resolution below 320 by 240 is rejected with IllegalArgumentException.
  • Defaults. LaunchOptions.defaults() returns 2048/4096 MB, no custom resolution, 854 by 480, recommended flags on, and "release".
  • Fallback. LaunchOptionsReader falls back to LaunchOptions.defaults() when the stored values are invalid.

The feature flags these options produce are matched by RuleEvaluator at launch — see launch command construction.

04 / Java

Java executable override.

The java.executable key points the game at a Java runtime of your choosing instead of the official one CT installs.

  • Empty means official runtime. When java.executable is empty (the default), the installed official Java runtime is used — the one under runtimes/<component>/<version> described in runtime.
  • Override mechanism. The java.executable key stores the path; empty means the installed official runtime is used. Installation.withRuntimeExecutable(Path) returns a copy of the installation that uses a different Java executable, which is how the override is applied at launch.
  • Runtime is still installed. The official runtime is downloaded and verified regardless; the override only changes which executable starts the game.

Set it in settings.properties or through the launcher's directories card. Because of the persistence behavior below, edits made in the window may not affect the next launch — see window behavior.

05 / Desktop

What the window persists.

The desktop launcher persists some settings through its window and re-reads others from the file. Knowing the split avoids lost edits.

  • Persisted by the window. The window persists the Microsoft sign-in method (microsoft.loginMode), the Microsoft client ID (microsoft.clientId), and the offline player name (offline.playerName).
  • Read from the file. The memory, resolution, game directory, and Java executable fields are read from settings.properties when the window opens, and the launch reads the settings file again.
Edits to those four fields in the window do not change the next launch. Set them in settings.properties, or use the command line flags — this is the workaround for the current limitation.

Command line mode additionally has no Microsoft sign-in and no offline name persistence. The complete current-limitations list is in features, and the window's v4.3.0 layout in interface.