"A second s&box instance on the same Steam account can make P2P joins fail rendezvous"

A P2P join to a live remote host dies with the engine's timeout:

Timed out attempting to negotiate rendezvous

even though the host has a fresh, advancing liveness beat. Closing your extra instances and retrying connects on the first attempt.

Running a second s&box process under the same Steam account — an editor or dev instance open alongside the published client you're testing with — correlates with P2P joins failing rendezvous inside the engine's fixed ~3.5 second connect budget.

Observed on engine 26.07.15a: with a dev instance open, two browser joins to a host with a fresh, advancing liveness beat both died with Timed out attempting to negotiate rendezvous. The signature: the same Message Session Failed ... (Timed out attempting to negotiate rendezvous) line for the remote's steamid appeared simultaneously in both processes' logs, with different connection handles — meaning both processes held a messages session with that host. Incoming signaling for the one account was being answered by two listeners. After closing every second instance, the same lobby connected on the first attempt.

Mechanism is a lead hypothesis, not a controlled A/B. The host's own state changed between the failing and succeeding attempts, so this has strong log support but hasn't been isolated in a host-state-controlled repro. Treat the mechanism as guidance pending that repro — but the practical rules below hold regardless.

• Close every second same-account instance before drawing any conclusion from a P2P connectivity failure. A backgrounded editor is enough to contend for the account's signaling.
• When triaging a failure, grep the other process's log for the same session-failure line at the same timestamp. Two handles on two processes for one remote steamid is the signature of this contention.

P2P rendezvous is negotiated per Steam account, not per process. When two processes on the same account both hold a messages session with the host, the host's incoming signaling for that account can be answered by the wrong listener, and neither handshake completes inside the fixed ~3.5s budget. Collapsing to a single instance leaves exactly one listener for the account's signaling, so rendezvous completes.

The never-closed session poisoning a pair produces the same player-facing timeout. Discriminate by prior-pairing history: the poisoned-pair wedge needs a previous session with that steamid to have ended uncleanly; this multi-instance contention does not — it happens on a first join. If there's no prior pairing with the host, suspect a second same-account instance first.