Reset a declined ZombieBuddy Java mod approval

Confirm this is an approval problem

First confirm the loader is running. A missing loader indicator belongs in installation troubleshooting, not an approval-file reset. If available, use Better ModList to distinguish a blocked Java file from one that loaded.

Write down the mod ID, actual JAR path, fingerprint and whether the decision was saved or only applied to the session. A similarly named Workshop item is not necessarily the file you intended to run. If an update changed the file, review that version again instead of assuming the old approval covers it.

Undo one saved denial

The pinned author documentation places the decisions at %USERPROFILE%\.zombie_buddy\mod_approvals.json on Windows, or ~/.zombie_buddy/mod_approvals.json on macOS/Linux. Use the actual user account that launches the game.

1. Exit the game. Copy the existing file to a dated backup before editing.
2. Open it in a plain-text editor. Under mods, identify the exact mod ID and hash entry you recorded.
3. Remove only that hash's saved decision, preserving the other decisions and valid JSON punctuation.
4. Save the file and restart through the working launch method.
5. At the prompt, check the mod ID, full path, modification time and SHA-256 fingerprint before choosing allow or deny.

If you cannot identify the entry or keep the file valid, stop and retain the backup. Do not erase the whole configuration folder to repair one mistake. A session-only denial is different from a persisted decision; check what was actually saved.

If restarting still produces no prompt

Confirm the intended mod is enabled for this session and the loader started. The documented default policy is prompt; deny-new skips unfamiliar files without asking. Review the existing loader options if you deliberately changed this policy.

Do not switch to allow-all to make a missing prompt disappear. If a signature requirement or another loading error blocks the file, changing one approval cannot repair that different prerequisite. Preserve the failure log and compare it with the log collection checklist.

Verify the decision and the feature separately

After restarting, inspect the intended file's loaded/blocked state and saved/session decision. Then test its feature in a separate world: an allowed file and a correctly functioning camera or companion are separate observations.

Keep the old backup until the change is understood. An approval is your choice to run that code; the path and fingerprint identify it but do not certify its safety or compatibility. This flow documents the author's mechanism, not a gameplay or security test on your computer.