computer use not working: black screens and misclicks

When computer use fails, do not reinstall first. Black screenshots, misclicks, permission prompts, and no response map to capability, coordinates, gating, and loading; layer diagnosis is faster than repeated installs.

Triage: four symptoms, four layers

The same "does not work" has four different causes. Identify the symptom before choosing a layer.

Triage prevents reinstalling in the wrong layer, and symptoms can stack. Permissions never improve with reinstall, and coordinate problems never improve with a plugin change. If both black screens and offsets appear, fix the black screen first (permission), then the offset (coordinates). One layer at a time.

Symptom one: black or blank screenshots

Two possibilities: no permission, or the wrong target was captured.

1. Check whether a screenshot call occurred. A call with a black image points to system permission; no call means the flow never reached the screenshot step.
2. Check system authorization. macOS requires screen recording permission; Windows and Linux differ. Restart the app after granting it.
3. Confirm which display was captured. Multiple monitors or virtual desktops may capture an empty desktop instead of the target window.
4. Test another target. Use a system window as a control to separate "all windows are black" from "this app blocks capture."

Permission-related black screens have a signature: the call succeeds, the image is empty. Reinstalling does nothing; grant the permission in system settings.

Some apps block capture. Protected windows, DRM content, and security overlays may never be capturable. Change the target instead of continuing to debug the plugin.

Symptom two: misclicks and offsets

Offsets are almost always coordinate conversion, not the agent aiming badly. Coordinates come from the screenshot but land in another coordinate system.

1. Set scaling to 100 percent. A mismatch between system scaling and screenshot resolution shifts coordinates proportionally.
2. Keep one monitor. Each display has its own origin; a mismatched arrangement sends clicks to the wrong screen.
3. Use the same coordinate system for capture and click. Some implementations use physical pixels, others logical; mixing them makes the offset vary with scaling.
4. Retest with a fixed element. Click a button that does not move three times. A stable offset means coordinate conversion; a random offset means recognition or page loading.

A stable offset is the key signal. Stable means coordinates; random means element recognition or page load, a different direction.

Fullscreen versus windowed also affects coordinates. Retest after switching window mode to rule out borders and title bars.

Symptom three: repeated permission prompts

The prompt is not a bug; it is the tool gate doing its job. It blocks unapproved desktop actions, not plugin loading (source).

1. Read the prompt. Is it asking for screen permission, a specific window, or a wider sandbox? Each maps to a different setting.
2. Read the gate policy. Does the current profile's approval scope cover the tool? Too narrow causes repeated prompts; too wide removes protection.
3. Shrink the task. Let the agent operate the target window instead of the whole desktop; a narrower scope needs fewer approvals.
4. Keep approvals. Do not disable them for convenience; desktop actions carry higher risk than ordinary tools.

Repeated prompts mean policy and task do not match. Either the task is too broad or the approval rule is too fine; narrowing the task is safer than disabling approval.

Do not treat "turning off prompts" as a fix. Actions run, but the interception disappears; align task scope with approval scope instead.

Symptom four: no response at all

No response means the call never happened. Check loading, sandbox, and gating.

1. Loading: does dsh plugin --profile web list contain the plugin? If not, wrong profile or interrupted install.
2. Sandbox: computer use needs wider authorization than ordinary tools; the default minimal profile is often insufficient (source).
3. Gating: was the tool denied by policy? The log should contain a denial, not silence.
4. Compatibility: only after the first three check system and plugin version compatibility.

"Nothing happened" is rarely true. The log should contain a load, denial, or timeout record; if not, you are reading a different profile's log.

Five-minute evidence collection

When time is short, collect evidence in this order.

1. Symptom: black screen, offset, prompt, or no response.
2. Log: tool call, denial, or timeout; each points to a different layer.
3. Single variable: change only scaling, only monitor, or only approval scope.
4. Control: switch target window or profile; a different result means the environment, not the plugin.
5. Versions: system, plugin, and profile names in the record.

The goal is narrowing the range, not finding a single culprit. Eliminating three layers leaves the direction.

Restore defaults and turn it off

After diagnosis, put temporary changes back.

1. Scaling and monitors: restore the original settings.
2. Approval scope: return to the previous scope and keep key approvals.
3. Sandbox: return to the minimum usable level; turn computer use off when unused.
4. Test artifacts: keep screenshots and logs separate from real sessions.

The goal is a known-good state, not defaults. If defaults do not fit the task, record the working configuration for reuse.

When not to use computer use

computer use has a wider permission surface than browser control; avoid it when possible.

1. Web automation only: use browser-control plugins for a narrower surface and more predictable behavior.
2. File or command work only: use built-in tools; no desktop operation is needed.
3. Irreversible tasks: payments, deletions, and system settings should not be delegated to unattended desktop automation.

Least privilege applies here too. Do not open computer use for tasks that do not need the desktop, and turn it off after use.

Next steps

Triage, collect evidence, restore. For enablement and boundaries, read How to enable computer use. To distinguish browser control from desktop actions, read Browser control plugins. For sandbox modes, read What DeepSeek Harness sandbox does.

Sources: dsh-computer-use plugin page, DeepSeek Harness docs - Process sandbox, DeepSeek Harness docs - Tool subsystem