THE SHORT ANSWER
Roblox is making PlayerCharacterDestroyBehavior the default behavior on November 11, 2026. This automatically destroys Player instances 5 seconds after PlayerRemoving handlers run and Character models right after CharacterRemoving handlers. Games relying on the old behavior must update data-saving code to read values before yielding, or temporarily set the property to Disabled. The opt-out option will be removed entirely by end of February 2027.
- PlayerCharacterDestroyBehavior becomes default on November 11, 2026, matching Enabled behavior
- Player instances destroyed 5 seconds after PlayerRemoving; Characters destroyed after CharacterRemoving
- Code that yields before reading Player/Character children will break; must read values first
- 16% of games already opted in over three years; Studio templates ship with it enabled
- Phase 3 removes opt-out entirely by end of February 2027
Roblox is flipping the switch on a memory-leak fix that has been optional for nearly three years. On November 11, 2026, the engine will treat PlayerCharacterDestroyBehavior = Default the same as Enabled across every experience. The change automatically destroys Player instances five seconds after PlayerRemoving handlers finish and Character models immediately after CharacterRemoving handlers run, closing a leak path that has kept servers alive for dozens of hours in some games.
What's Changing
The property was introduced as an opt-in in late 2023. About 16 percent of games have enabled it, and all current Studio templates ship with it on. With Phase 2, the behavior becomes the baseline:
- Player instances: Destroy called five seconds after PlayerRemoving handlers complete. The engine holds only a weak reference during that window, so normal garbage collection still applies.
- Character models: Destroy called right after CharacterRemoving handlers finish.
What Could Break
Any script that yields before reading a Player's or Character's children will start returning nil. The classic pattern is a data-save handler that waits, then reaches into leaderstats or other values. After November 11, the instance is gone.
Roblox provided a migration example:
- Before (breaks): wait, then read player.leaderstats.Points.Value
- After (works): capture userId and points at the top of the handler, then wait and save
The same rule applies to CharacterRemoving: copy everything you need before the first yield. Re-parenting a destroyed Player or Character will also fail.
Immediate Steps for Developers
If your experience already has the property set to Enabled, nothing changes. If it sits at Default, the engine team recommends switching to Enabled now and playtesting with focus on data saving and leaderboard logic. If something breaks, you can temporarily set the property to Disabled, but treat that as a stopgap.
Timeline to Full Enforcement
Phase 3 arrives at the end of February 2027. At that point the opt-out disappears, the property is removed, and the destroy behavior applies everywhere. The three-month window is intended for testing and migration.
Community Response
Forum reactions were mixed but largely pragmatic. Several developers noted the change resolves memory leaks that killed servers after extended uptime. Others asked about client-side parity and questioned the forced timeline, though most acknowledged the leak-prevention rationale. The engine team is monitoring the thread for edge cases before the November 11 rollout.