If you can't join a friend's server in Permafrost, first confirm that your friend used Play and Host Multiplayer to open the intended world. Loading a solo game does not create a joinable session. The host must also reach the cabin before guests can join. Then check both clients are updated, an available player slot exists, and the password matches exactly.
Steam invitations now work with an important condition: the joining player must launch Permafrost and wait at the main menu before accepting the invitation. The in-game Join Multiplayer Sessions route is also available. Neither route guarantees success for every remaining connection fault, so identify whether the failure is finding the session, entering the password, loading, or staying connected.
Agree on one host and one world
Permafrost uses a player-hosted world, with up to four players total including the host. Decide which friend will host and which existing world you intend to continue. If everyone starts hosting separate worlds, you have several independent sessions rather than one shared playthrough.
The host controls the world save and must be online in the game for guests to play there. A server-list entry is not a permanent dedicated server that remains available after the host leaves. If the host closes the session, the guest cannot independently continue that host-owned world.
Write down the world or session name before reconnecting later. The same host can have more than one world, and returning to the right person is not enough if that person has opened the wrong save. This distinction matters after a break when the connection works but the environment or progress appears unfamiliar.
For a returning group, the host should reload the same world through Host Multiplayer. Creating a fresh world to make the session appear is not a substitute for reopening the existing shared progress. Keep the original world identifiable while testing connection steps.
Open the world through Host Multiplayer
The host should perform the full hosting sequence from the main menu:
- Choose Play.
- Choose Host Multiplayer.
- Select the world you want to use.
- Set or confirm the password.
- Set the player slots for the group.
- Start the hosted session.
- Reach the cabin if this world is still in the opening sequence.
Interface reference: begin with Play, then choose the multiplayer route; this image does not show the host or session-browser screen.
The key check is Host Multiplayer. A host who loads a solo session and then tells friends to search has not completed the joinable-session setup. Correct that before investigating browser filters or asking every guest to recreate a character.
Check the player count as part of setup. Four is the total session limit, not four guests plus the host. If a slot is occupied or the host selected too few slots, another guest may not have a place to enter. Verify the available capacity rather than repeatedly retrying an unchanged session.
Keep the chosen password explicit. A password that looks familiar can still contain an extra leading or trailing space. Confirm the same text on both sides, especially if it was copied from a message. Do not make repeated password guesses while leaving the host's actual setting unchecked.
Let the host reach the cabin
Guests can join after the host reaches the cabin. In a newly started world, get the host through that opening requirement before treating a missing session as a separate network fault. Guests do not all need to host their own worlds to satisfy the condition for this session.
Early discussion advice sometimes suggested both players needed to progress independently. The clarified requirement belongs to the host's world. Do not use an older report to turn the current cabin condition into a demand for every friend to complete a separate solo introduction.
This condition is especially useful when distinguishing a new world from a returning session. A brand-new world may still be in the opening sequence. A world where the host has already progressed beyond the cabin should be checked for hosting mode, update state, password, and slots instead of blindly repeating the introduction.
After the host reaches the required point, have one guest attempt to join. A single clear test is easier to interpret than several players switching methods at the same time while the host is still changing session settings.
Use the in-game session browser as a complete route
The joining player starts from the main menu, selects Play, then Join Multiplayer Sessions. Find the intended session, enter its password if required, and load into it. Treat finding the session and successfully entering the world as separate milestones.
If the session is absent, confirm the host has started a multiplayer session and is still in it. Check the exact session name, the host's selected world, and the cabin prerequisite. These are concrete setup checks you can resolve before assigning the failure to an unknown network cause.
If the session appears but joining fails, note the point at which it fails. Does the password receive a rejection, does loading begin and then return to the menu, or does the guest enter and immediately leave? Each description is more useful than saying the browser does not work.
Do not assume seeing the friend's name elsewhere in Steam means the in-game session is correctly configured. Steam presence and a joinable Permafrost world are related steps, but the host still needs the multiplayer route and world prerequisites.
Accept Steam invitations from the main menu
The latest verified update adds working Steam invitations with the joining player already at Permafrost's main menu. Use this sequence:
- Have the host open the correct world through Host Multiplayer.
- Confirm the host is past the cabin requirement.
- Launch Permafrost on the joining player's computer.
- Leave the joining player at the main menu.
- Send or accept the Steam invitation for that hosted session.
- Observe whether the game begins loading and whether the guest remains connected.
Do not follow the old launch-era instruction to keep the joining player's game closed as the current invitation procedure. The present condition is that the game is running and the guest is at the main menu. Also avoid accepting from inside a different world while trying to evaluate this specific route.
If an invitation does not complete the join, record what happened and use the in-game browser as a separate test. Switching routes can help identify whether the failure belongs to a particular entry method, but it does not prove that one method bypasses every underlying connection problem.
Update and restart both clients before repeating the test
When setup appears correct, confirm that both players have installed the available game update. Close and restart both game clients, then have the host reopen the same world through Host Multiplayer. Do not compare a fresh host session with a guest whose client was left running through an update.
Keep the exact build shown by each installation when it is available. The latest verified announcement is Quest Fixes & Steam Invites, but its exact build number was not established here. Do not label every connection attempt with an older build simply because that number appears in an earlier troubleshooting discussion.
After restarting, retest one route from beginning to end. Keep the password, selected world, and slots consistent. If you change all three at once, you may obtain a working session without knowing which original setting caused the problem.
Missing or invalid authentication token, or a greyed multiplayer option, has separate current guidance: Steam must be in online mode and the VPN should be off. Apply those checks if that is the state you actually see. A session that is merely hard to find does not automatically have a token error.
Handle a return to menu without deleting progress
If loading begins and the guest is returned to the main menu, note that the session was discoverable and the failure occurred later. That narrows the problem compared with an absent session. Confirm the host remained online, the intended session is still open, and both clients are updated before retrying.
Avoid creating a new world or deleting a character as the first response. Neither action is a documented universal solution for being returned to the menu. It also makes the next test harder to compare because you have changed the world as well as the connection procedure.
A temporary reconnection attempt should keep the same host and world. If the group chooses to test another world for diagnosis, label it as a separate test and preserve the original. A successful join in the test world establishes that particular result; it does not explain why the original session failed.
Distinguish a successful join from a character-transfer expectation
Entering a friend's world with a fresh character is not proof that the connection failed. Characters are tied to worlds, and a separate solo character cannot be carried into the friend's world. The guest's return progress belongs to that same host world, not to every world opened by the same friend.
For a returning guest, check that the host selected the original world before diagnosing lost gear or progress. If it is the same world and expected state is still absent, record the discrepancy as a persistence issue. Do not describe it as a missing-session problem when the guest has already entered successfully.
The same distinction applies to quests. Guests synchronize with the host world's progress, but current guidance asks the host to perform main story and Skinwalker steps. A successful connection therefore does not guarantee that any player can perform every story interaction interchangeably.
Keep the next retry specific
Before another attempt, the group should be able to state the host name, world name, hosting mode, cabin status, available slots, password status, update status, and chosen joining route. That is a complete session checklist rather than a collection of unrelated tweaks.
Record the last successful stage: session absent, session found, password accepted, loading started, world entered, or disconnect after entry. If the supported checks still leave the same failure, the cause remains unresolved. Keep that precise result for further diagnosis instead of inventing a port number, promising that a firewall change will fix it, or repeatedly reopening new worlds that discard the context of the original session.