DeepSeek Harness ENOENT after update: missing runtime fix

After updating and restarting, the dialog says "The application could not start or stopped unexpectedly", Restart gives the same sentence, and the crash log holds a single line: ENOENT ... office-skills\office\SKILL.md. It is tempting to think one file is missing, but in fact the whole resources\runtime directory is empty — none of the 6150 files in the installer payload ever reached disk. The key is to count files and verify hashes first, because "lost during write" and "never packaged" require completely different responses (#10861).

DeepSeek Harness: Experiment 1: count files to separate an empty directory from a missing file

An existing but empty resources\runtime is the most typical shape of this failure; thousands of files present with only SKILL.md missing is the genuinely single-file case.

1. Open the install directory, go into resources\runtime, and look at the file count.
2. Count with one line: (Get-ChildItem -Recurse -File).Count, and note the result.
3. Check the rest of the install directory: in the community case all 1661 files outside runtime were present and matched the installer in size, and only runtime was empty.
4. Compare with the installer payload: the same version's runtime holds 6150 files, including bin, cli, office-skills, primary-runtime, and versions.json.
5. Zero against 6150 means a write problem that can be refilled; if the directory has 6150 and still errors, move on to single-file checks.

Also rule out three common misreads: disk space (the case machine had 178 GB free on D), path length (the longest inside runtime was 174 characters), and symlinks (none inside runtime).

DSH plugin: Experiment 2: verify the extracted payload before overwriting anything

Before refilling you must prove you have a payload that is the same version, complete, and unmodified; otherwise you are layering a second problem on top of the first.

1. Find the cached package: %LOCALAPPDATA%\@deepseek-ai\dsh-desktop-updater\pending\deepseek-harness-<version>-win-x64.exe.
2. Verify the download first: its sha512 should match what pending\update-info.json records.
3. Open the exe with 7-Zip and extract $PLUGINSDIR\app-64.7z.
4. Unpack resources\runtime from that 7z into a temporary directory on its own.
5. Verify: the file count should be 6150 and the total size about 257.3 MiB.
6. Spot-check a key file: office-skills\office\SKILL.md should exist and be 957 bytes.

# run inside the extracted runtime directory
(Get-ChildItem -Recurse -File).Count
(Get-Item .\office-skills\office\SKILL.md).Length
Get-ChildItem -Recurse -File | Get-FileHash -Algorithm SHA256

In the successful community recovery, all 6150 restored files passed SHA-256 verification, the full session UI appeared about 24 seconds after refilling, and both the account and sessions were preserved.

DeepSeek Harness: Experiment 3: decide whether it was never packaged

If the file is missing from the installer too, stop trying to refill; that is a build-time gap with no user-side fix.

1. Open the installed Resources\app.asar and look only at the file index, not the contents.
2. Find the target directory — in the macOS case, @deepseek-ai/dsh-experimental-cua-macos/native/bin/ — and count entries.
3. The community result was 0: the whole asar index has 657 files including lib/index.js, Package.swift, 23 Swift sources, tests, and schema, but not a single entry under native/bin/, for either x64 or arm64.
4. Compare app.asar.unpacked/: it contains node-pty, koffi, and sherpa-onnx-darwin-x64, so the packager does ship native payloads — this package simply had nothing to ship.
5. Confirm the load path: prepareNativeExecutable() compiles only when isSourcePackage() detects a repo checkout, and otherwise calls access(path, X_OK), which must produce ENOENT.
6. Conclusion: this is a packaging gap and manual compilation does not help — ElectronAsarIntegrity in Info.plist records the asar header hash, so inserting files fails integrity checks unless you rewrite the hash and re-sign the whole bundle.

One more thing in the same case: a platform requirement stacked on top. The helper's README states macOS 14+ only, and that machine was on 13.7.1. A packaging gap and an unsupported platform are two separate problems; do not infer one from the other.

DSH Plugin: Experiment 4: make sure refilling will not hit "directory in use"

Refilling and the updater's rename are different things: refilling only writes files and does not rename the install directory, so a busy CWD cannot block it; when the update itself failed, fix the rename step first.

1. If the update finished without a restart and the version did not change, look for MoveFileExW in the installer log.
2. Error 32 means the target directory is some process's current working directory — the installer inherited the shortcut's "start in" path, so it is renaming its own CWD.
3. Error 5 means a file inside is open; in the community case a VS Code tool subprocess held handles under resources\runtime\dli\bin, and closing VS Code made the update succeed.
4. Both errors retry 10 times, abort with exit code 2 after about 60 seconds, and leave roughly 1 GB in a .new-{GUID} staging directory.
5. Once no leftover process remains, run the pending package from a directory outside the install tree, such as %TEMP%.

DeepSeek Harness: Refill: mirror with Robocopy, delete nothing else

Refill by mirroring into resources\runtime, adding only the missing files and leaving everything else in the install directory alone.

1. Quit DSH completely and confirm Task Manager has no DeepSeek Harness process.
2. Put the runtime extracted in experiment 2 into an independent temp directory, such as D:\tmp\runtime.
3. Run the mirror copy: robocopy "D:\tmp\runtime" "D:\herness\resources\runtime" /MIR /COPY:DAT /DCOPY:DAT /R:1 /W:1.
4. Recheck afterwards: RUNTIME_FILE_COUNT=6150, OFFICE_SKILL_EXISTS=True, and zero Robocopy failures.
5. Start the app and confirm the session UI opens, menus respond, and no new crash log appears.

If the installer is stuck on the directory rename on another machine, the same robocopy idea works: mirror the .new-{GUID} staging directory into the original install directory, then start.

DSH plugin: Cautions

Verify counts and hashes before you overwrite a single file.

1. Do not add only the file named in the error. SKILL.md is just the first file read; missing the other 6149 still means it cannot run.
2. Do not use runtime from a different version. A version mismatch introduces compatibility problems that are much harder to trace; use the payload from the same version and architecture.
3. Do not reinstall repeatedly after a failed update. A reinstall fails the same way when the rename is blocked; resolve the lock first.
4. Do not stuff files into the asar by hand. On macOS the integrity check rejects it, which is by design rather than a defect.
5. Keep the logs and verification records. File count, total size, and SHA-256 results are the only basis for deciding whether recovery really succeeded.

If your installer's runtime is empty as well, this article cannot solve it: re-download a complete installer or wait for the official packaging fix.See DeepSeek Harness desktop: no window, crash, EMFILE, 80s for the related case.