Project Zomboid Safehouse Multiplayer: Claim Rules

Project Zomboid safehouse multiplayer rules are split across separate server settings for claiming, entry, loot, fire, and respawn. The generated configuration inspected for Build 42.21.0 documents the exact keys and their defaults, but it does not prove what a player client can do. Use this reference to find the settings, distinguish their scopes, and run an owner, member, and visitor check on your own server before relying on a claim.

Read the settings from the correct server file#

If you first need to locate the active configuration or verify an edit, use the Project Zomboid server INI guide for that separate workflow.

Start with the build number and the server’s own generated configuration. In the inspected Build 42.21.0 server, the file was Zomboid/Server/servertest.ini. servertest is the example server name; another server configuration may have a different name. The generated artifact confirms that this build writes the listed options in an .ini file, while the official ServerOptions API lists typed fields. Neither source confirms that your running server has loaded a particular file or that a player-facing action behaves exactly like its comment.

Write down the build, server name, and file path before changing anything. Compare your live file with a fresh backup after a restart. If a setting is missing, don’t copy a path from an old Build 41 post and assume it applies to Build 42; find the configuration generated by your own server version. The key spelling SafehouseAllowTrepass is unusual, but it is the spelling in the inspected generated file. Keep it exact when searching or comparing settings.

The values below are the generated defaults observed in Build 42.21.0, not a recommended preset. A changed file, server update, mod, or runtime behavior can make your environment differ. Treat the file as a map of available controls, then test the account and action that matter to your group.

Choose who may create a claim#

The generated comments distinguish player claims from admin claims:

These are two separate switches, not a single “safehouses on” value. The comments describe what each option controls, but do not tell us how the combination behaves for every account or whether an admin can bypass normal membership checks. Decide which accounts should be eligible, inspect both values, and test with an ordinary player account. Keep an admin account out of the visitor test: elevated permissions can make a normal-role check meaningless.

For a controlled check, use a low-value building in a disposable or backed-up world. Record which account attempts the claim, whether it succeeds, and the exact server build. If an ineligible account still claims the building, stop and check the loaded configuration, mods, and server logs before changing more options. Do not infer that false means “nobody can claim” from one setting in isolation; the second claim option has its own documented scope.

Set claim eligibility and removal separately#

Two other settings use different clocks and answer different questions. The generated Build 42.21.0 file gives SafehouseDaySurvivedToClaim=0, measured in in-game days survived before claiming, with a generated minimum of 0 and maximum of 2147483647. It gives SafeHouseRemovalTime=144, measured in real-world hours without a visit before removal, with the same generated numeric limits. Preserve the capital H in SafeHouseRemovalTime exactly as shown.

Don’t compare 0 and 144 as if they were durations on the same clock. If you raise the survival requirement, verify it with an account whose survival time is known. If you change the removal period, record the timestamp and check what your current server does after the relevant real-world interval; this guide does not claim to have waited through that interval. Back up the world first if an incorrect eligibility rule could disrupt a shared run.

Separate visitor entry, loot, and fire rules#

The generated file lists three independent controls for actions by non-members. Its exact setting name for entry includes the engine spelling Trepass:

Changing one does not document the result of changing the others. For example, the entry key alone does not establish what happens to a container interaction, and the loot key is not a promise about every object, mod, or admin action. Check each desired setting in your generated file and verify each action separately with a non-admin visitor. Use an expendable container and items for any transfer test.

The official Build 42.21 Stable release announcement follows an Unstable note that safehouse exploits were remedied, but the public note does not identify the affected actions or keys. That is a reason to retest after updates, not evidence that a particular permission now works or that every exploit is closed.

Keep respawn and world-loot behavior distinct#

The official Build 42.21 Unstable release note is the source for its brief note that safehouse exploits were remedied; it does not identify the affected actions or keys.

Several settings mention safehouses without controlling the same outcome. The inspected generated file documents these defaults and comments:

The comments identify separate switches; they do not establish every prerequisite or client-visible result. In particular, the respawn comment does not prove that a former member will appear there automatically, that no in-game choice is needed, or that all builds behave the same. If respawning there matters, test the flow with a disposable character and record whether the player was a member before death, the selected spawn, the setting value, and the server build.

Likewise, don’t treat SafehousePreventsLootRespawn as a setting that prevents player theft. It refers to world loot respawning, which is a different question from whether another account can take an item. Keep the two checks separate in your notes. If the owner-connected option matters to your group’s access policy, test it with the owner both online and offline instead of deriving the outcome from its label.

Run an owner, member, and visitor acceptance check#

This is a test plan for your server, not a report of tests performed for this article. Use three ordinary accounts with known roles. Avoid admin privileges, valuable items, and a world you cannot restore. Fill the observed-result column only after each attempt, and note the exact build and whether the server restarted after a setting change.

1. Back up and identify the build

   Save a copy of the world and settings file. Write down the server version, configuration name, and whether mods are enabled.

2. Record the relevant values

   Copy each key and value exactly, including the unusual SafehouseAllowTrepass spelling. Restart only as required by your server workflow, then confirm you’re checking the intended server.

3. Use ordinary test accounts

   Run one action per row with owner, member, and visitor identities. Record what the client actually allows rather than filling in expected results from the comments.

4. Repeat after a relevant change

   After changing a setting, build, or mod, repeat only the affected checks and keep the old and new observations with their build numbers.

If your results do not match the intended policy, confirm that you edited the configuration for the server that is actually running and that the new values were loaded. Then isolate mods or role differences one at a time. Don’t broaden permissions or leave a test world exposed while diagnosing. An admin successfully entering a claimed house is not evidence that an ordinary visitor can do the same.

Set limits before relying on the claim#

A safehouse claim is not a universal anti-grief guarantee. The generated settings and their comments do not establish coverage for PvP, admins, mods, every interaction, every container, or all kinds of item loss. The public Build 42.21 note about remedied safehouse exploits does not describe the exploit details. Keep backups, agree on group rules, and test the exact action you want to control before storing anything important.

If you are comparing a result across versions, include the full build number, settings file, and account roles. “The visitor got in” is more useful when paired with the exact entry value and whether the account had admin or faction privileges. Faction membership and safehouse membership are not established as interchangeable by the settings listed here; verify invitations and claims separately rather than assuming one grants the other’s permissions.

For a separate overview of running the game as a multiplayer server, see the Project Zomboid server setup guide, if you need help locating the server setup workflow. It covers a different task; it is not proof of any safehouse permission behavior.

FAQ#

Can admins and regular players both claim a safehouse?

The generated Build 42.21.0 comments document separate player and admin claim switches. Check both values and verify the effective rule with ordinary accounts; no author-run claim result is available here.

Does allowing entry also let visitors take items?

Entry and item access are separate generated settings. Test container and item interactions separately on your build before storing anything valuable.

Does a safehouse protect every item and action?

No. These options do not establish a blanket guarantee for every object, mod, PvP rule, admin action, or loss.

Can a former member respawn at a safehouse?

The generated comment says the respawn option concerns a safehouse where the player was a member before death. Test your current build’s full respawn flow, including any selection the game presents.