DeepSeek Harness present.open 500 and Open With List Fix

Two Windows symptoms in DeepSeek Harness (DSH) look unrelated but share one code path: clicking a file card returns 500, or the Open With list is full of irrelevant apps and selecting one freezes the assistant. Neither is a corrupt file. The handler enumerator in file-applications-windows has no per-item error handling and passes the wrong filter flag. This guide separates the two symptoms, gives three fixes you can apply independently, and ends with a verification set that covers all of them.

DeepSeek Harness Open With failures: 500 versus a dirty list

Bottom line: a constant 500 means one broken handler aborts enumeration, while irrelevant entries mean enumeration is not filtered. The first needs per-item error handling; the second needs a different filter flag. Map what you see to the code path:

According to the reproduction in the discussions, the GET and POST forms of present.open consume the same enumeration result. The GET fails whenever enumeration throws, while POST calls ShellExecute directly and is unaffected (#10322). For other platform faults, see common Windows platform errors.

Why DeepSeek Harness breaks on one bad handler

Bottom line: the 500 comes from calling GetName and GetUIName without a per-item catch, and the dirty list comes from passing filter 0 to SHAssocEnumHandlers; both live in the same enumerator file. The same file already catches errors per item when fetching icons at :163-165; the name lookup is the one place that was missed.

Cause 1: one broken handler aborts enumeration

The trigger is ordinary: an editor that was uninstalled, a portable tool, or a broken ProgID leaves a handler pointing at a missing executable. COM returns E_FAIL when the loop reaches it, nothing catches it, and the exception reaches the endpoint.

Cause 2: filter 0 returns every historical registration

With filter 0, SHAssocEnumHandlers returns everything that ever registered the extension, not everything that can open it. The registry does not distinguish "declared support once" from "still handles this type". The hang after selection is a separate effect: an incompatible app may wait for input that never arrives, so the launch watcher never sees a clean exit and the UI stays on "Opening".

Confirm it is the filter, not registry pollution

1. Run Get-ItemProperty "Registry::HKEY_CLASSES_ROOT\.cmd\OpenWithProgids" in PowerShell and count the ProgIDs; expected: every candidate registered for that extension is listed.
2. If the count is far larger than the two or three you expect, filter 0 is pulling in historical registrations; expected: the scope narrows to the enumeration layer.
3. Temporarily set the filter to 1, restart DSH, and inspect the same list; expected: unrelated entries disappear without registry edits.

Three DeepSeek Harness fixes for the Open With path

Bottom line: if you can change source, do per-item error handling and the filter together; if you cannot, clean the registry; if you only need relief, switch the filter and add the empty-set fallback.

Fix A: wrap the name lookup in try/catch

This is the smallest change and the right one when you can modify source but do not want to change the enumeration range. The principle is that one bad record must not erase the whole table.

1. Open packages/util/native-command/src/file-applications-windows.ts and find the GetName and GetUIName calls around :202-204; expected: two consecutive name lookups.
2. Wrap both calls in try/catch; in the catch block continue to the next handler instead of returning; expected: the bad entry is skipped and the loop continues.
3. Log a warning with the handler CLSID or executable path; expected: the log identifies the broken registration.
4. Rebuild and restart DSH, then click the same file card; expected: HTTP 200 and only usable entries remain.

Fix B: change the filter flag and add a fallback

If a clean list matters more than showing every possible app, change the second argument from 0 to 1 so Shell returns only recommended handlers. Premiere and similar apps that merely registered the extension will disappear.

1. In the same file around :181-185, locate SHAssocEnumHandlers(extension, 0, ...); expected: the second argument is currently 0.
2. Change the second argument to 1 (ASSOC_FILTER_RECOMMENDED); expected: only recommended handlers are returned.
3. For extensions that may return an empty set, such as .cmd and .bat, fall back to ShellExecute with the default verb; expected: the empty dialog is avoided.
4. Test .txt, .cmd, and an extension with no default app; expected: all three produce a sensible result.

Fix C: remove broken handlers from the registry

When you cannot modify code, clean entries that point at missing executables so enumeration becomes healthy again. This is suitable for managed environments or emergencies, but back up first.

1. Under HKEY_CLASSES_ROOT\<extension>\OpenWithProgids, review each ProgID; expected: all candidates are listed, and built-in entries stay untouched.
2. For each ProgID, open HKEY_CLASSES_ROOT\<ProgID>\shell\open\command and check whether the executable still exists; expected: stale entries pointing at missing paths are identified.
3. Export and delete only the stale references inside OpenWithProgids; expected: Explorer double-click behavior is unchanged.
4. Restart Explorer with taskkill /f /im explorer.exe && start explorer.exe, then retry the file card in DSH; expected: the list shrinks to usable entries and the 500 is gone.

Apply them in that order if you need all three, so each step can be verified independently. Use Fix A when you need a working card now, add Fix B when the list is visibly dirty, and use Fix C only when code changes are impossible.

Verify DSH fixes and avoid regressions

Bottom line: four samples — normal file, script file, extension without a default app, and a deliberately broken handler — are needed to cover listing, launching, and fault tolerance. Steps:

1. Prepare note.txt, task.cmd, a .foo file with no default program, and a test ProgID whose shell\open\command points at a missing executable; expected: all four paths are covered.
2. Click each card in DSH; expected: the first three show a usable list and the fourth does not return 500.
3. Select a non-default app for .cmd; expected: the UI no longer hangs forever, and if it does, that handler is broken.
4. Open Task Manager; expected: no associations.ps1 or orphan editor process remains.
5. Restart DSH and repeat step 2; expected: the fix survives a fresh process.

Avoid these traps:

• Do not delete system ProgIDs under HKEY_CLASSES_ROOT just to clean the list; remove only references inside OpenWithProgids, or Explorer double-click behavior may break.
• Filter 1 intentionally hides some older apps; provide a "Choose another app" path instead of reverting the filter.
• Per-item error handling only covers enumeration; if the selected DSH plugin itself blocks, end it in Task Manager and rely on a launch timeout plus a clearer message.
• Both symptoms still reproduce on 0.2.1-rc.2 according to the discussions; treat release notes as the source of truth if a fix ships.

DeepSeek Harness Open With FAQ

Q: Why does DeepSeek Harness present.open return 500 while POST action=open still opens the file? A: A 500 from DeepSeek Harness present.open means handler enumeration failed, not that the file path is broken. GET and POST share the same enumeration result, while POST calls ShellExecute directly; wrapping the name lookup in try/catch restores the list.

Q: Why does DeepSeek Harness list Premiere for a .cmd file and hang when it is chosen? A: DeepSeek Harness lists unrelated apps because SHAssocEnumHandlers receives filter 0 instead of ASSOC_FILTER_RECOMMENDED. Change the flag to 1 and fall back to the default verb when the result is empty; if a chosen app still hangs, end it in Task Manager.

Q: Why is the DeepSeek Harness Open With list empty for .cmd even after registry cleanup? A: An empty DeepSeek Harness list for .cmd points at the filter flag or a missing empty-set fallback, not at the registry. With filter 1 some systems return zero candidates, so the code must fall back to ShellExecute before you inspect OpenWithProgids.

Q: How do I verify the DeepSeek Harness Open With fix so the assistant no longer hangs? A: A complete DeepSeek Harness verification needs four samples: a text file, a .cmd script, an extension with no default app, and a deliberately broken handler. Confirm each lists and launches correctly, the broken one never returns 500, and no associations.ps1 remains.