Desktop window opens taller than the screen, cutting the bottom of dialogs

[amotasan]

On a 1920x1080 display at 100% scaling (work area 1872x1080), DeepSeek Harness Desktop opens its main window at 1888x1208 and does not clamp it to the work area, so the window extends 128 px below the bottom edge of the screen.

Most visible symptom: the Settings modal (760x500, centered in the window) has its lower part clipped, including the Apply/Cancel buttons. The "... More" button in the sidebar footer - the only entry point to Settings - is covered too. Content anchored at the bottom becomes unreachable.

Reproduced on 0.2.0-rc.2 and again after updating to 0.2.1-rc.3, so the update did not fix it.

Notes that may help:

• The window is NOT maximized when this happens. Maximizing works around it, because the content area then becomes exactly 1872x1080.
• No window geometry seems persisted: Preferences and Local Storage in %APPDATA%@deepseek-ai\dsh-desktop contain no width/height/isMaximized data, so the size looks computed at startup.
• Expected: clamp the default/restored window size to the current work area (or start maximized), so a 1208 px-tall window is never requested on a 1080 px work area.

Workaround in use: a small background script that maximizes the window whenever it does not fit. Happy to test a fix.

[Muguett-DBY]

One detail that may help narrow this down: the public rc.2 and rc.3 sources create the main window with a size of 1280 × 820. That differs from the size you observed, but it doesn't establish whether the size changes later or the measurements use different units.

How did you measure the window and work area? If you have a source build available, a main-process log taken while the window is oversized could compare Electron's window bounds and display work area directly:

// Import screen from electron in the main process.
const bounds = window.getBounds()
const display = screen.getDisplayMatching(bounds)
console.log({ bounds, workArea: display.workArea, scaleFactor: display.scaleFactor })

Electron documents the work area in device-independent pixels. I haven't reproduced this on your installed build, so I can't tell yet what caused the difference.

[amotasan]

Thanks — happy to give the exact numbers and the units. ## How I measured (from outside the app; no source build here) - `GetWindowRect(hwnd)` — Win32, **physical pixels** - `DwmGetWindowAttribute(hwnd, DWMWA_EXTENDED_FRAME_BOUNDS)` — **physical pixels** - `GetMonitorInfo(MonitorFromWindow(hwnd, MONITOR_DEFAULTTONEAREST)).rcWork` — **physical pixels** - `GetDpiForWindow(hwnd)` = 96 and `GetDpiForMonitor(...)` = 96x96, i.e. **scaleFactor 1.0**, so on this machine physical pixels == DIPs - `IsZoomed(hwnd)` for the maximized state - enumerating the child `Chrome_RenderWidgetHostHWND` to get the **content** area ## State when I filed the report Windows 11, single monitor **1920x1080**, taskbar docked on the **right**, **100 % scaling**: | Value | Measurement | |---|---| | Desktop | 1920x1080 px | | `display.workArea` (DIP) | `{x:0, y:0, width:1872, height:1080}` (48 px taskbar on the right) | | `window.getBounds()` (DIP) | `{x:-8, y:0, width:1888, height:1208}` | | `display.scaleFactor` | `1` | | Maximized? | **no** (`IsZoomed == false`) | So the window was **128 px taller** than the work area and the bottom of it was unreachable. ## Three observations that may help 1. **1888 == workArea.width + 16**, which is exactly the width Windows reports for a *maximized* window on that display (maximized rect = work area + 8 px per side). The height does **not** follow that rule: maximized height there was 1096, not 1208. 2. The oversized state appeared **only after restarting / updating** the app. Freshly started it was maximized, with a content area of exactly **1872x1080**. That points at **restored ("normal") bounds**, not at the creation size. 3. The app also seems to **maximize its own window at startup** — I never maximize it at launch and it comes up maximized. ## About 1280x820 That size never showed up in any measurement on this machine, neither maximized nor restored, so I can't confirm nor rule it out. Also worth asking on your side: **is the window geometry persisted anywhere?** Here, ***@***.***\dsh-desktop` has no width/height/isMaximized JSON (only `Preferences`, `Local State` and `Local Storage`), so I could not find where 1888x1208 comes from. ## Current situation (problem no longer reproduces) I have since **changed the display myself** to **2560x1440** at 100 % scaling (this was my own display change, not an app or OS update): | Value | Measurement | |---|---| | workArea (DIP) | `{x:0, y:0, width:2512, height:1440}` | | window (DIP), maximized | `{x:-8, y:-8, width:2528, height:1456}` = workArea + 16 per axis | | content area | 2512x1440 | | Settings modal | fits, nothing clipped | So with a taller work area the symptom disappears, which is consistent with "the restored bounds were simply taller than the screen". ## Running your snippet I don't have a source build — installed version is **0.2.1-rc.3** (`app.asar` sha256 04B32E3A…). If you can provide a build with that log, or tell me where to hook it, I'll reproduce it and paste the exact `getBounds()` / `workArea` / `scaleFactor` output. The Win32/DWM values above should map 1:1 to Electron's on this machine because `scaleFactor` is 1, but confirming it with the real `getBounds()` would settle it. For completeness, the workaround I'm running meanwhile: a small background script that maximizes the window whenever it does not fit. Happy to drop it once this is fixed upstream.

…

________________________________ De: Caldera ***@***.***> Enviado: jueves, 29 de octubre de 2026 17:57 Para: deepseek-ai/deepseek-harness ***@***.***> Cc: Antonio Mota Sandoval ***@***.***>; Author ***@***.***> Asunto: Re: [deepseek-ai/deepseek-harness] Desktop window opens taller than the screen, cutting the bottom of dialogs (Discussion #11466) One detail that may help narrow this down: the public rc.2<https://github.com/deepseek-ai/deepseek-harness/blob/639ed015397290b3745d163aafe02ffee4aa3f84/apps/desktop/src/main.ts#L208-L213> and rc.3<https://github.com/deepseek-ai/deepseek-harness/blob/1f81c047fc48fa190a683e469daa699857e9afe8/apps/desktop/src/main.ts#L208-L213> sources create the main window with a size of 1280 × 820. That differs from the size you observed, but it doesn't establish whether the size changes later or the measurements use different units. How did you measure the window and work area? If you have a source build available, a main-process log taken while the window is oversized could compare Electron's window bounds and display work area directly: // Import screen from electron in the main process. const bounds = window.getBounds() const display = screen.getDisplayMatching(bounds) console.log({ bounds, workArea: display.workArea, scaleFactor: display.scaleFactor }) Electron documents the work area in device-independent pixels<https://www.electronjs.org/docs/latest/api/structures/display>. I haven't reproduced this on your installed build, so I can't tell yet what caused the difference. — Reply to this email directly, view it on GitHub<#11466?email_source=notifications&email_token=BG6HLCSAM7ULI6X2UF2W6GL5WNZIZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJSG4ZTCOBQUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-19273180>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BG6HLCX3HVA7XWKCFNCAP4D5WNZIZAVCNFSNUABJKJSXA33TNF2G64TZHMYTGMZTGA3DKMBZGE5UI2LTMN2XG43JN5XDWMJRGE3TSNBUGGQXMAQ>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[Muguett-DBY]

Thanks, the 96-DPI measurements clarify the scaling question. They still aren't a direct Electron getBounds() read, so I'd leave the exact frame comparison open.

On your persistence question: I searched the public rc.3 apps/desktop/src TypeScript and JavaScript files and didn't find code that saves or restores the main window's geometry. The constructor requests 1280 × 820. The onboarding handler can widen a narrow window, but retains its existing height. That source search doesn't rule out behavior elsewhere, Windows itself, or a difference in your installed build.

One detail that might matter when distinguishing a restart from a reopen: on Windows, the normal close handler hides the main window and keeps its page and process alive. Reopening a hidden window can therefore retain its in-memory bounds. If the process actually exited during your update or restart, that wouldn't explain the oversized new window.

I used OpenAI Codex for the source search; I haven't reproduced the installed app. Since the issue is no longer visible on your current display, I wouldn't change it back or install a custom build just for this check. If it recurs, whether the process fully exited or the window was only hidden may help narrow it down.

[amotasan]

Follow-up after a genuine restart (same day, 20:17)

I restarted the app completely (quit, not just close the window). New process, and the first state
line after it came up:

20:17:30  pid=8040  rect=(-8,0)-(2520,1448)  2528x1448  max=False  work=2512x1440

So, against the prediction I made from the earlier numbers:

	Predicted	Measured
width	2528	2528	matches workArea.width + 16
height	1568	1448	matches workArea.height + 8, not +128

So the "+128" was specific to that earlier state, not a constant: my hypothesis is wrong on the
height, and the 1208 px from the report is still unexplained. What does repeat across both
measurements is the width: workArea.width + 16 (1888 when the work area was 1872, 2528 when it is
2512).

Two things this suggests, for what it is worth:

1. On the current display the window overflows the work area by only 8 px (bottom 1448 vs work
   area 1440) — the invisible resize border. That is why the dialog is fine now: it was 128 px in the
   earlier state.
2. A fresh process sizes itself relative to the current work area (width + 16), which argues
   against a fixed 1280x820 surviving to the first paint — so the earlier 1208 may have come from
   bounds captured in an earlier session with a different display or taskbar geometry, rather than
   from the constructor value.

I'm keeping the logger that records pid + rect + maximized + work area on every change, so if it
recurs there will be a timestamped sequence to look at. No action needed from you on my account.

[amotasan]

It recurred — same process, and the normal size is reproducible

Short update, because this answers the "did it exit or was it only hidden" question from a second angle: it recurred without any restart.

I switched the display back to 1920x1080 (work area 1872x1080) while the same main process kept running (it had been up since the previous evening). The window then came back at:

rect = (1,1)-(1871,1209)   1870x1208   not maximized   work area 1872x1080

So the bottom edge sat at y=1209, i.e. 128 px below the work area, and the Settings modal was clipped again (same symptom as the original report).

It is reproducible on demand: pressing Restore returns the window to 1870x1208 at (1,1) every time, same PID, no restart involved.

The "+128" now has two data points

work area	normal window	delta (w / h)
1872x1080	1870x1208	−2 / +128
1872x1080 (measurement from the report)	1888x1208	+16 / +128
2512x1440	2528x1448	+16 / +8

Two things I notice, and I am not drawing conclusions from them:

• On a 1080-high work area the height overshoot is 128 px; on a 1440-high one it is 8 px.
• The width delta is not constant either: −2 in one case, +16 in the others, which does not look like a single frame-padding constant.

Since scaleFactor is 1 on this machine, those numbers are DIPs and should map 1:1 to getBounds() — but I still agree it is not a direct read.

No action requested. If a build with the getBounds() / workArea log ever exists, I can reproduce this on demand and paste the exact values in one run. My local workaround (maximizing the window when it does not fit) now reads the work area live via MonitorFromWindow/GetMonitorInfo, since the cached value from System.Windows.Forms.Screen was stale after the resolution change and that is what let this slip through on my side.