Update loop / evidence-led repair

Stop Luczystrap reinstalling Roblox on every launch

Q: Why does Roblox reinstall when the force option is off?

Issue #164 records ForceReinstall as false while the expected managed executable did not exist and the deployed version GUID differed from the current production GUID, so _mustUpgrade became true. The trace proves that force is not the only input to the install decision, but it does not prove one universal cause for every loop.

One installation after Roblox publishes a new version can be normal. Installing again on the next unchanged launch means Luczystrap is repeatedly reaching an upgrade decision, failing to retain the completed state, or finding the managed player missing.

Do not begin with another full reinstall. Save the installation log and the immediately following launch log, then compare the two force fields, version GUIDs, expected executable, and _mustUpgrade. Those values identify the decision that is repeating.

Written by Luc6iEvidence checked July 30, 2026Applies to public release 1.4.9

01 / LAUNCHRead saved state

02 / DECIDE_mustUpgrade

03 / INSTALLDeploy + save

04 / NEXT RUNRead again

LOOP

The second log reveals which state failed to settle

6Direct issue threads

Public reports explicitly describing an install on every launch.

2Complete state traces

Issues #164 and #218 expose the decision inputs before installation.

0Universal fixes documented

The public tracker does not establish one repair that resolves every loop.

01 / Recognize the loop

A second launch is the test

Do the comparison only after one installation reaches its successful end. If the first installation was interrupted or failed with access denied, you have an incomplete install—not yet proof that completed state is being forgotten.

Expected update

Install once, then launch normally

The current production version changes. Luczystrap installs it, records the new state, and the next log shows matching version GUIDs, File.Exists=True, and _mustUpgrade=False.

Reinstall loop

The same decision returns next launch

No intentional force request or new Roblox version exists, but the next log again shows force active, stale or blank version state, a missing managed executable, or _mustUpgrade=True.

02 / Read the decision gate

Six fields explain more than the progress bar

The installer animation only says work started. The log exposes why Luczystrap selected that work and whether the last deployment became usable state.

Until I can reproduce and verify one repair across supported systems, I treat this as a state-decision loop, not a one-click fix.

ForceReinstall

Explicit request. It should be False for a normal comparison.

LaunchSettings.ForceFlag.Active

Active launch force. Confirm this is also False; the two values are recorded separately in public traces.

AppData.State.VersionGuid

Luczystrap’s saved deployed version. A blank or old value can disagree with the current Roblox version.

Player VersionGuid

Player state read from RobloxState.json. Compare it with the current version fetched for the selected channel.

ExecutablePath / File.Exists

Managed player check. False means the expected RobloxPlayerBeta.exe was not found at the path Luczystrap checked.

_mustUpgrade

Result of the decision. If this is True again on launch two, the preceding fields help explain the repeated branch.

03 / What the tracker proves

The same symptom reaches different states

Six issue threads use the same broad description, but the detailed records do not support one cause. These three reports set the useful boundaries for a safe repair sequence.

Issue #25↗

Turning force off was not enough

The reporter said Force Roblox Reinstallation was already off and that removing AppData plus fully reinstalling Luczystrap did not stop the behavior. That rules out presenting either action as universal.

Force option: OFF · full reset: tried · loop: retained

Issue #164↗

Force false; upgrade still selected

The log records ForceReinstall=False, a missing expected executable, a deployed GUID different from the current production GUID, and _mustUpgrade=True. Installation then completed and state was saved.

force: FALSE · file: FALSE · versions: DIFFERENT · upgrade: TRUE

Issue #218↗

Blank state; install could not finish

The trace shows force true, blank version values, a missing executable, and an install that stopped on RobloxCrashHandler.exe access denied. An incomplete deployment can naturally be selected again.

force: TRUE · versions: BLANK · file: FALSE · install: DENIED

04 / Preserve a two-launch diff

Keep both sides of the loop

Copy the first log before launching again. Name the files by order and time so the second run cannot be mistaken for the install run.

%LocalAppData%\Luczystrap\Logs\

If your log shows another location, use the path it records. Do not clear logs, state, or version folders until both copies are safe.

Field	Launch 1: install	Launch 2: verify
Time and Luczystrap build	Record exact values	Same build, later time
Selected channel	Record exactly	Must remain the same
`ForceReinstall`	`False` for normal test	`False`
`ForceFlag.Active`	`False` for normal test	`False`
Saved / player / current GUID	May differ before update	Should match after completion
`ExecutablePath`	Copy the full managed path	Same expected path
`File.Exists`	May be false before install	`True`
`_mustUpgrade`	May be `True`	Should be `False`
Completion markers	`Installation complete` `Save complete` `Started Roblox`	No install branch expected

05 / Controlled repair

Change one decision input at a time

Stop as soon as launch two no longer installs. Keep the successful comparison logs until you have completed another normal launch.

Baseline

Save two consecutive logs

Keep the current install log and the next launch log. Record the channel, time, build, six decision fields above, and whether the first run reached every completion marker.

Do not reinstall, clear AppData, or restore an old backup before capturing this pair

Remove intent

Turn off force and exit Test Mode

Open settings, disable Force Roblox Reinstallation, and exit Test Mode if it is active. Save, close Luczystrap, reopen it, and confirm ForceReinstall=False and LaunchSettings.ForceFlag.Active=False in the fresh log.

If both were already false, do not cycle the setting repeatedly. Move to the version and file checks.

Stable comparison

Use the intended production channel

If you knowingly selected a custom Roblox channel, return to the normal production or default channel for this test. Confirm the channel recorded in the log. A channel change can legitimately change the current version GUID.

Do not edit registry channel data or guess a channel string from an old forum post.

Complete deployment

Restart once and permit one full install

Restart Windows once. Close any remaining Roblox Player, Luczystrap, and RobloxCrashHandler processes. Launch Luczystrap and allow one installation to finish without cancelling it.

The useful end state is not “the bar reached 100%.” Keep the log until it records Installation complete, Save complete, and Started Roblox.

After Roblox closes, exit Luczystrap normally and start the verification launch

Failed install boundary

Resolve access denied before retesting

If deployment stops on a locked executable, the state cannot settle through a successful install. Use the matching guide for RobloxCrashHandler.exe access denied or RobloxPlayerBeta.exe access denied.

Return here only after one installation completes. Do not grant broad folder permissions, take ownership of the whole profile, or disable security globally.

Contradictory force state

Back up and isolate State.json

Use this only if the UI is saved with force off but a new log still says force is active. Close Luczystrap, back up %LocalAppData%\Luczystrap\State.json, then rename the original to State.loop-backup.json. Reopen Luczystrap, complete the First Launch Experience, and keep force off.

Luczystrap 1.4.9 release notes explicitly say removing State.json replays the First Launch Experience. Renaming preserves an undo path.

Undo: close Luczystrap, move the newly created State.json aside, and restore the backed-up filename

Blank player state

Isolate RobloxState.json once

Use this only when the install reached completion but the next log still reads a blank or stale player VersionGuid. Back up and rename RobloxState.json to RobloxState.loop-backup.json, allow exactly one clean installation, then inspect the next launch log.

This is a reversible diagnostic test, not a maintainer-confirmed universal fix. If the new GUID is saved and retained, keep both before-and-after files until a second normal launch.

File disappears

Check the exact managed path

If GUIDs match but File.Exists=False on launch two, copy the exact ExecutablePath from the log. Inspect Windows Security and third-party protection history at the installation and next-launch times. Record whether the file exists before and after Roblox closes.

Do not whitelist the whole Luczystrap, Roblox, AppData, or user folder. A matching event and exact file path are required before making a narrow protection decision.

Last resort

Clean recovery without restoring the loop

Back up logs, profiles, mods, plugins, and settings. Follow the Luczystrap uninstall guide, install the verified official 1.4.9 release, leave force and Test Mode off, and run the two-launch test before restoring optional data.

Restore one category at a time only after the clean state passes. Remember that issue #25 reports one full AppData reinstall that did not resolve the symptom, so do not erase the diagnostic logs first.

06 / Read the result

The second log decides the next lane

Classify the state, not the user-visible pause. A long first launch may be expected; the decisive question is whether the same install branch returns.

Launch-two state	Interpretation	Next action
Force false, GUIDs match, file true, upgrade false	The completed deployment was retained and no install is required.	Run one more normal launch, then archive the comparison.Loop stopped
Current GUID changed once, then matches	Roblox published or selected a different version and Luczystrap completed a normal update.	No repair is needed if the following launch stays normal.Normal update
Force false, GUIDs match, file false	The expected managed executable is absent despite matching recorded version state.	Check the exact path and security history; report when the file disappears.File boundary
Install stops with access denied	The deployment did not complete, so the next launch may select installation again.	Use the matching handler or player guide.Resolve first
Save complete, then GUID blank again	The public evidence does not establish why state was not retained.	Stop resetting. Submit both logs and the backed-up state files.Report state loss
Official Roblox works; Luczystrap loops	The problem is more specific to Luczystrap’s managed deployment path or state.	Include this controlled contrast in the Luczystrap issue.Luczystrap lane
Official Roblox also fails to install	The failure is not isolated to Luczystrap.	Use the official Roblox repair path before changing more Luczystrap state.Roblox/system lane

Report the retained loop ↗Return to error index →

07 / Preserve the signal

Do not turn one loop into nine unknown changes

Each safe step above has a before state, one change, a next-launch result, and an undo path. Broad cleanup removes that evidence.

Do not repeatedly delete the Luczystrap folder
The 1.4.9 release note describes removing %LocalAppData%\Luczystrap\ once before that release, not as a per-launch repair.
Do not hand-edit JSON values
Back up and rename one relevant state file. Manual edits can create a state Luczystrap never wrote.
Do not force ownership or recursive permissions
Resolve the exact denied executable with the scoped access guide.
Do not disable antivirus globally
Inspect matching history and use exact paths. Never exclude all of AppData or the user profile.
Do not restore mods, plugins, and settings before the clean test
First prove the default two-launch path; then restore one category at a time.
Do not call every first install a loop
A new Roblox version or a deliberate force request can make one installation expected.

08 / Escalate with a diff

Report the decision that repeated

A title saying “keeps installing” confirms the symptom but not the branch. Paste the values from both launches and attach both complete logs.

Open GitHub issue ↗

Reinstall-loop report template

Luczystrap version:
Windows edition, version, and OS build:
Launch 1 date/time/time zone:
Launch 2 date/time/time zone:
Selected Roblox channel:
Force Roblox Reinstallation UI state:
Test Mode state:

LAUNCH 1
ForceReinstall:
LaunchSettings.ForceFlag.Active:
AppData.State.VersionGuid:
Player VersionGuid:
Current channel VersionGuid:
ExecutablePath:
File.Exists:
_mustUpgrade:
Installation complete / Save complete / Started Roblox:

LAUNCH 2
[repeat every field above]

Official Roblox comparison:
One variable changed:
Result and undo performed:
Both complete logs attached:
Relevant backed-up state files attached:

Redact private data. Remove Windows usernames from paths, account identifiers, tokens, cookies, and unrelated URLs. Keep version GUIDs, public endpoints, timestamps, filenames, Windows build, and decision fields.

Common questions

Roblox reinstall loop FAQ

What makes Luczystrap reinstall Roblox?

A reinstall can be requested explicitly by a force setting or selected when Luczystrap decides the managed Roblox deployment must be upgraded. Public traces show that this decision can coincide with a missing expected executable, a blank or different version GUID, or an incomplete installation. A single install after Roblox publishes a new version is normal; repeating it on the next unchanged launch is the problem.

How do I turn off Force Roblox Reinstallation?

Open Luczystrap settings, turn off Force Roblox Reinstallation, exit Test Mode if it is active, save, close Luczystrap, and reopen it. In the new log, verify that ForceReinstall and LaunchSettings.ForceFlag.Active are both false. If they already are, do not keep toggling the option; continue with the version and file checks.

Why does Roblox reinstall when the force option is off?

Issue #164 records ForceReinstall as false while the expected managed executable did not exist and the deployed version GUID differed from the current production GUID, so _mustUpgrade became true. The trace proves that force is not the only input to the install decision, but it does not prove one universal cause for every loop.

Can I delete State.json or RobloxState.json?

Do not delete either file as a first step. Save both launch logs and make a backup first. The 1.4.9 release notes say removing State.json replays the First Launch Experience. Rename one relevant file at a time so it can be restored, and use the next log to decide whether the state was involved.

Is one Roblox reinstall after an update normal?

Yes. If Roblox publishes a new production version, one completed installation followed by a second launch where the version GUIDs match, the executable exists, and _mustUpgrade is false is normal update behavior. It is a loop only when installation is selected again without a new version or an intentional force request.

Should I reinstall Luczystrap or Roblox?

Not first. Issue #25 says that removing AppData and fully reinstalling Luczystrap did not stop one reporter’s loop. Preserve and compare two logs before a clean recovery. If stock Roblox is also broken, use Roblox’s official reinstall guidance; if only Luczystrap loops, keep the Luczystrap state evidence and report that contrast.

Evidence trail

Public records behind this guide

Issue reports establish occurrence and recorded state, not a universal repair. Release notes define the documented migration and version-fetch behavior; Roblox Support defines the stock-player recovery boundary.