Keep Hyprland fallback bound to the requested target tab

In the headed Hyprland path, /screenshot now calls tryHyprlandViewportCapture with only browserPid, which captures compositor output for the browser window rather than the selected CDP target. Because ensureTabAvailable(targetId) does not activate/focus that tab, requests for a background targetId can return an image of a different tab/window, so automation can read or act on the wrong page state.

Useful? React with 👍 / 👎.

Preserve requested image format when Hyprland capture succeeds

When type: "jpeg" is requested, the Hyprland branch assigns the raw grim output directly to buffer, but grim emits PNG bytes. saveNormalizedScreenshotResponse only converts on resize/compression pressure; otherwise it keeps the original buffer and labels it from the requested type, which can produce .jpeg media IDs backed by PNG content and break consumers that rely on consistent output format.

Useful? React with 👍 / 👎.

Race condition in singleton setup

Because detectHyprlandSession() and setupHeadedBrowserViewportCapture() both contain await points, two concurrent screenshot requests that both enter the if (!cachedCapture) branch will each proceed through setup independently. Both dispatch movetoworkspacesilent for the same PID; the second write to cachedCapture silently overwrites the first, leaving the first capture object abandoned without teardown.

Fix: deduplicate concurrent callers with a shared in-flight promise:

let setupInFlight: Promise<HeadedBrowserViewportCapture | null> | null = null;

if (!cachedCapture) {
  if (!setupInFlight) {
    setupInFlight = (async () => {
      const session = await detectHyprlandSession();
      if (!session) return null;
      return await setupHeadedBrowserViewportCapture({ browserPid: params.browserPid, session });
    })().finally(() => { setupInFlight = null; });
  }
  const capture = await setupInFlight;
  if (!capture) return null;
  cachedCapture = capture;
  cachedPid = params.browserPid;
}

This is a comment left during a code review.
Path: extensions/browser/src/browser/hyprland-capture.ts
Line: 421-449

Comment:
**Race condition in singleton setup**

Because `detectHyprlandSession()` and `setupHeadedBrowserViewportCapture()` both contain `await` points, two concurrent screenshot requests that both enter the `if (!cachedCapture)` branch will each proceed through setup independently. Both dispatch `movetoworkspacesilent` for the same PID; the second write to `cachedCapture` silently overwrites the first, leaving the first capture object abandoned without teardown.

Fix: deduplicate concurrent callers with a shared in-flight promise:

```ts
let setupInFlight: Promise<HeadedBrowserViewportCapture | null> | null = null;

if (!cachedCapture) {
  if (!setupInFlight) {
    setupInFlight = (async () => {
      const session = await detectHyprlandSession();
      if (!session) return null;
      return await setupHeadedBrowserViewportCapture({ browserPid: params.browserPid, session });
    })().finally(() => { setupInFlight = null; });
  }
  const capture = await setupInFlight;
  if (!capture) return null;
  cachedCapture = capture;
  cachedPid = params.browserPid;
}
```

How can I resolve this? If you propose a fix, please make it concise.

PNG/JPEG format mismatch when type === "jpeg"

grim always outputs PNG. When type === "jpeg" and the screenshot fits within normalizeBrowserScreenshot's limits (< 5 MB, dimensions ≤ 2000 px — the typical case for a 1920×1080 viewport), normalizeBrowserScreenshot returns { buffer } with no contentType. The fallback image/${params.type} evaluates to "image/jpeg", so the saved file is labeled as JPEG despite containing raw PNG bytes.

Fix: override type to "png" for the Hyprland branch:

if (hyprlandPng) {
  await saveNormalizedScreenshotResponse({
    res,
    buffer: hyprlandPng,
    type: "png", // grim always produces PNG
    targetId: tab.targetId,
    url: tab.url,
  });
  return;
}
buffer = await captureScreenshot({
  wsUrl: tab.wsUrl ?? "",
  fullPage,
  format: type,
  quality: type === "jpeg" ? 85 : undefined,
});

This is a comment left during a code review.
Path: extensions/browser/src/browser/routes/agent.snapshot.ts
Line: 378-389

Comment:
**PNG/JPEG format mismatch when `type === "jpeg"`**

`grim` always outputs PNG. When `type === "jpeg"` and the screenshot fits within `normalizeBrowserScreenshot`'s limits (< 5 MB, dimensions ≤ 2000 px — the typical case for a 1920×1080 viewport), `normalizeBrowserScreenshot` returns `{ buffer }` with no `contentType`. The fallback `image/${params.type}` evaluates to `"image/jpeg"`, so the saved file is labeled as JPEG despite containing raw PNG bytes.

Fix: override `type` to `"png"` for the Hyprland branch:

```ts
if (hyprlandPng) {
  await saveNormalizedScreenshotResponse({
    res,
    buffer: hyprlandPng,
    type: "png", // grim always produces PNG
    targetId: tab.targetId,
    url: tab.url,
  });
  return;
}
buffer = await captureScreenshot({
  wsUrl: tab.wsUrl ?? "",
  fullPage,
  format: type,
  quality: type === "jpeg" ? 85 : undefined,
});
```

How can I resolve this? If you propose a fix, please make it concise.

No process-exit cleanup for headless compositor output

The browser-capture headless output is never removed on process exit (SIGTERM, crash, normal exit). On next run ensureCaptureOutput will find and reuse it, so it is not permanently leaked, but the dangling monitor is visible to users in their Hyprland session.

Consider registering exit handlers that call teardownHeadedBrowserViewportCapture(cachedCapture) once, lazily, when the first capture is set up.

This is a comment left during a code review.
Path: extensions/browser/src/browser/hyprland-capture.ts
Line: 417-419

Comment:
**No process-exit cleanup for headless compositor output**

The `browser-capture` headless output is never removed on process exit (`SIGTERM`, crash, normal exit). On next run `ensureCaptureOutput` will find and reuse it, so it is not permanently leaked, but the dangling monitor is visible to users in their Hyprland session.

Consider registering exit handlers that call `teardownHeadedBrowserViewportCapture(cachedCapture)` once, lazily, when the first capture is set up.

How can I resolve this? If you propose a fix, please make it concise.

Serialize teardown with capture for mixed-profile screenshots

Guarding only setup with setupLock leaves capture and teardown unsynchronized: if a screenshot for PID A is already in captureViewportPng, a concurrent request for PID B will execute teardownHeadedBrowserViewportCapture on the shared output immediately. That can invalidate the in-flight grim capture for PID A, causing an avoidable fallback to the original CDP timeout path and flaky failures whenever two profiles are snapshotted in parallel.

Useful? React with 👍 / 👎.

Tear down Hyprland output on capture fallback errors

The error path clears cachedCapture/cachedPid and returns null without cleaning up a headless output that may already have been created (and possibly had the browser moved onto it). After transient setup/capture failures, this can leave browser-capture state behind until a later successful PID-switch teardown happens, so a one-off failure can persistently alter compositor state.

Useful? React with 👍 / 👎.

Clean up cached Hyprland output when capture session ends

browser-capture teardown currently runs only when another screenshot arrives with a different PID (or when a capture error is thrown), so a successful screenshot followed by browser stop/restart can leave the headless Hyprland output and moved window state behind indefinitely. This makes /screenshot introduce persistent compositor side effects across runs instead of being self-contained; adding lifecycle cleanup outside the PID-mismatch path (for example on profile stop/shutdown) would prevent orphaned outputs.

Useful? React with 👍 / 👎.

Capture only tab viewport in Hyprland fallback

captureViewportPng runs grim -o <output> and the route returns that buffer as the /screenshot result, which captures the full compositor output rather than the page viewport that Page.captureScreenshot normally returns. On headed Linux this can include browser chrome and non-content pixels (for example when the window is not exactly full-output), so downstream consumers that rely on viewport-faithful screenshots for visual reasoning or click targeting get incorrect imagery whenever the Hyprland fallback path is taken.

Useful? React with 👍 / 👎.

Bind Hyprland screenshot to the requested target tab

The Hyprland branch calls tryHyprlandViewportCapture with only browserPid, so this path has no tab-level selector and can only capture whatever window/tab is currently visible for that PID. Because /screenshot accepts targetId and ensureTabAvailable(targetId) does not activate/focus that tab, background-tab requests can return an image from a different tab/window, which can mislead later automation steps.

Useful? React with 👍 / 👎.

Avoid reusing arbitrary Hyprland outputs by fixed name

ensureCaptureOutput reuses any existing monitor named outputName instead of tracking whether this code created it. With the default fixed name (browser-capture), a screenshot request can attach to an output created by another OpenClaw process or user workflow, then reconfigure it and later remove it during teardown, causing cross-session compositor disruption. Use a unique per-process output name and ownership tracking before mutating/removing outputs.

Useful? React with 👍 / 👎.