Theme background image is not dimmed in a 1px frame around the window #16690

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

With any theme whose background_image has an opacity below 100, a 1-point frame around the whole window shows the image at full strength, while everything inside the frame shows it dimmed to the theme's opacity. It looks like a thin line along all four window edges that takes the image's colors, bright or dark. The lower the opacity, the more it stands out. Warp's own picture themes show it too, for example Dark City.

To reproduce

Built-in theme:

1. Settings → Appearance → Themes → Dark City (its image opacity is 20).
2. Zoom into a window edge in a screenshot: the outermost 1 pt shows the photo undimmed.

Clearer, with a custom theme:

1. Put a solid red image at ~/.warp/themes/red.jpg (e.g. magick -size 1600x1000 xc:red red.jpg).
2. Save this as ~/.warp/themes/red-edge.yaml and select it:

name: red-edge
accent: "#ff7ab6"
background: "#1e151a"
foreground: "#e8dce2"
details: darker
background_image: {path: red.jpg, opacity: 10}
terminal_colors:
  normal: {black: "#2a2026", red: "#e06c75", green: "#98c379", yellow: "#e5c07b", blue: "#61afef", magenta: "#c678dd", cyan: "#56b6c2", white: "#d8ccd2"}
  bright: {black: "#6b5a63", red: "#ef8a92", green: "#b2d995", yellow: "#f0d49a", blue: "#86c3f5", magenta: "#d699e8", cyan: "#7cc9d3", white: "#f4ecf0"}

3. A bright red line runs around the whole window, while inside it the window is a dark, slightly red background.

Expected behavior

The edges show the image at the theme's opacity like the rest of the window, so no line appears.

Screenshots, videos, and logs

Attached, both from v0.2026.10.21.08.25.stable_02 on Linux:

1. GIF: the red-edge theme above at opacity 100 → 60 → 30 → 10, with the window's left edge enlarged 12×. The inside follows the opacity, but the 1px edge stays #fe0000 (the image at 100%) in every frame.
2. Dark City with its top edge enlarged 12×: the outermost row shows the photo undimmed (e.g. #13d9f1 on the edge, #0d3a44 one pixel in).

On macOS (Retina) the frame is 2 device px wide; a ttheme user's report with a screenshot: kecan0406/ttheme#39

Operating system (OS)

macOS

Operating system and version

macOS 27.0.1 (reporter in kecan0406/ttheme#39); also reproduced on Ubuntu 26.04 (X11)

Shell Version

No response

Current Warp version

v0.2026.10.21.08.25.stable_02 (latest stable); same code on master 5a55a2a

Regression

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

Recent working Warp date

No response

Additional context

Cause, from the source (master 5a55a2a; the same structure is in the v0.2026.06.03 stable):

• Workspace::render draws the image under the whole window: Image::new(img.source(), CacheOption::Original).cover() (app/src/workspace/view.rs L28053).
• The dimming overlay, util::get_terminal_background_fill (100 - img.opacity, util.rs L396), is painted only on the panels container (view.rs L26982),
• which sits inside Container::new(panels).with_uniform_padding(WORKSPACE_PADDING) (L27035; WORKSPACE_PADDING = 1.0 on native, L563). Nothing paints that 1px frame, so the image shows through at full strength. Without an image the frame shows surface_2.

Related: #15259 removed this same 1px frame on web, where it showed as a stray line; #14109 describes the terminal background container sitting 1px inside the root; #9474 fixed the overlay being painted twice for image backgrounds.

A possible fix: when the theme has a background image, paint the overlay on the padded container instead of on panels. Container::paint fills the padding too (crates/warpui_core/src/elements/gui/container.rs L306). The padding value stays, so the toast offset and PaneGroup::estimated_view_bounds that #15259 mentions are unaffected, and themes without an image keep their surface_2 frame.

Not a driver issue: the same on macOS and on Linux (X11 under Xvfb, Mesa software rendering).

https://github.com/warpdotdev/warp/blob/5a55a2ac/app/src/workspace/view.rs#L27035

Does this block you from using Warp daily?

No

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

No response