Unexpected X11 enforce on Linux platform

[FurryR]

Pre-submit Checks

• I have searched Warp bugs and there are no duplicates
• I have searched Warp known issues page and my issue is not there
• I have an issue with AI and have included the debugging ID (Optional, but helps expedite the AI quality fix). Debugging ID instructions
• I have technical issue and have included the logs (optional, but helps expedite the bug fix). Log instructions

Describe the bug

As title.

warp/app/src/settings/linux.rs

Lines 9 to 10 in ad73053

	// Default to true on WSL and false on all other platforms.
	default: !linux::is_wsl(),

Found when fixing the IME issue.

To reproduce

Launch the app.

Expected behavior

You know it.

Screenshots, videos, and logs

N/A

Operating system (OS)

Linux

Operating system and version

Any except WSL

Shell Version

Any

Current Warp version

Latest

Regression

No, this bug or issue has existed throughout my experience using Warp

Recent working Warp date

Use git blame

Additional context

If possible I will handle this issue. I'm preparing an fix for IME that @abhishekp106 was trying to do (despite that I haven't seen any related commits).

Does this block you from using Warp daily?

Yes, this issue prevents me from using Warp daily.

Is this an issue only in Warp?

Yes, I confirmed that this only happens in Warp, not other terminals.

Warp Internal (ignore): linear-label:b9d78064-c89e-4973-b153-5178a31ee54e

None

[oz-for-oss]

@FurryR

Here's what I found while triaging this issue:

• The current Linux startup logic appears to default to X11/XWayland on non-WSL Linux, which matches the behavior reported here.
• Until this is fixed, WARP_ENABLE_WAYLAND=1 or the “Use Wayland for window management” setting should enable native Wayland on supported setups after restart.

Maintainer details

I concluded that warp’s Linux force_x11 default appears inverted, causing non-WSL Linux launches to force X11/XWayland by default unless overridden..

Triage summary

This looks like an actionable Linux windowing bug rather than just an IME-related hypothesis. The report points at ForceX11, and the current code supports the claim that non-WSL Linux launches default to X11/XWayland unless explicitly overridden.

Evidence

• app/src/settings/linux.rs:7 defines force_x11 with the comment Default to true on WSL and false on all other platforms, but the expression is default: !linux::is_wsl(). That evaluates to true on ordinary Linux and false on WSL.
• app/src/lib.rs:1075 reads ForceX11; app/src/lib.rs:1077 allows Wayland only when WARP_ENABLE_WAYLAND=1 or force_x11 is false; app/src/lib.rs:1078 then calls app_builder.force_x11(!allow_wayland).
• crates/warpui/src/windowing/winit/app.rs:164 applies with_x11(&mut event_loop_builder) when force_x11 is true.
• app/src/settings_view/features_page.rs:7474 renders the user-facing switch as Use Wayland for window management with .check(!force_x11), which also supports the interpretation that force_x11=false is the native-Wayland path.

Likely fix direction

If the comment and setting semantics are intended, the default should likely be inverted to linux::is_wsl() or otherwise adjusted so WSL defaults to X11 while non-WSL Linux defaults to native Wayland when available. The existing WARP_ENABLE_WAYLAND=1 environment variable remains an override path.

Duplicate check

I enumerated open non-PR issues via the GitHub API and searched recent closed X11/Wayland candidates. #9836 is strongly related and proposes the same default inversion, but I did not mark this as a duplicate because the dedupe workflow requires two or more likely existing duplicate issues before applying the duplicate label.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[leesa-ui-w]

Hey @FurryR, thanks for digging into this and providing the exact code reference! This is the same inverted force_x11 default issue tracked in #9836 -- same lines, same proposed fix. We're going to close this one and keep the conversation over there. Feel free to drop your IME-related context into that thread too, since it sounds like you have some useful additional details.