Pre-submit Checks
Describe the bug
Summary
After locking the screen (session lock → display off) and logging back in on a dual-monitor setup, Warp's window size and UI scaling ratio change, requiring the user to manually resize and re-scale the window.
Problem
When using Warp on a dual-monitor system with different display resolutions/DPIs, locking the session (which turns off displays) and then unlocking it causes Warp to lose track of the correct window dimensions and scaling factor. On re-login, the window is either resized (wider/narrower) and the zoom/scaling ratio has changed compared to what it was before the lock.
To reproduce
Reproduction steps
Set up a dual-monitor configuration (monitors may have different resolutions or scale factors)
Open Warp, position and size it as desired, set the preferred zoom/scaling level
Lock the session (e.g., via loginctl lock-session or screen locker)
Wait for displays to turn off/sleep
Unlock the session and log back in
Observe that Warp's window size and zoom/scaling ratio have changed from the values set in step 2
Artifacts
None attached.
Expected behavior
Expected behavior
After session unlock, Warp should preserve its previous window size (width/height) and zoom/scaling ratio exactly as they were before the lock, regardless of display hotplug or DPMS events.
Actual behavior
Both window dimensions and zoom/scaling ratio are altered after unlocking the session. The user needs to manually resize the window and adjust the zoom level back to the desired values every time after re-login.
Screenshots, videos, and logs
Before:

After:

Operating system (OS)
Linux
Operating system and version
CachyOS
Shell version
zsh 5.9.1 (x86_64-pc-linux-gnu)
Zap version / commit
v2026.06.25.1
AI / BYOP path involved?
No — non-AI bug (terminal, blocks, UI, shortcuts, etc.)
BYOP provider (if applicable)
No response
Regression
No, this issue has existed throughout my use of Zap.
Last known good build / date (if regression)
No response
Additional context
No response
Does this block your daily use of Zap?
No
Reproducible only in Zap?
Only in Zap.
Pre-submit Checks
RUST_LOG=infooutput, panic traces, etc.). Optional, but greatly speeds up triage.Describe the bug
Summary
After locking the screen (session lock → display off) and logging back in on a dual-monitor setup, Warp's window size and UI scaling ratio change, requiring the user to manually resize and re-scale the window.
Problem
When using Warp on a dual-monitor system with different display resolutions/DPIs, locking the session (which turns off displays) and then unlocking it causes Warp to lose track of the correct window dimensions and scaling factor. On re-login, the window is either resized (wider/narrower) and the zoom/scaling ratio has changed compared to what it was before the lock.
To reproduce
Reproduction steps
Set up a dual-monitor configuration (monitors may have different resolutions or scale factors)
Open Warp, position and size it as desired, set the preferred zoom/scaling level
Lock the session (e.g., via loginctl lock-session or screen locker)
Wait for displays to turn off/sleep
Unlock the session and log back in
Observe that Warp's window size and zoom/scaling ratio have changed from the values set in step 2
Artifacts
None attached.
Expected behavior
Expected behavior
After session unlock, Warp should preserve its previous window size (width/height) and zoom/scaling ratio exactly as they were before the lock, regardless of display hotplug or DPMS events.
Actual behavior
Both window dimensions and zoom/scaling ratio are altered after unlocking the session. The user needs to manually resize the window and adjust the zoom level back to the desired values every time after re-login.
Screenshots, videos, and logs
Before:

After:

Operating system (OS)
Linux
Operating system and version
CachyOS
Shell version
zsh 5.9.1 (x86_64-pc-linux-gnu)
Zap version / commit
v2026.06.25.1
AI / BYOP path involved?
No — non-AI bug (terminal, blocks, UI, shortcuts, etc.)
BYOP provider (if applicable)
No response
Regression
No, this issue has existed throughout my use of Zap.
Last known good build / date (if regression)
No response
Additional context
No response
Does this block your daily use of Zap?
No
Reproducible only in Zap?
Only in Zap.