DeepSeek Harness macOS Dock duplicates: 939 session.lock

On seeing "939 session.lock files that are never reclaimed", almost every instinct points at "lock leak" and reaches for a cleanup script — which is exactly the step that turns cleanup into a concurrency bug. The same report also contains the other half: Dock icons piling up, and that one is the real defect (#10757). Read the two sentences separately and the conclusions are completely different.

DeepSeek Harness: What "939 lock files" actually means

It only says 939 sessions have existed in this workspace; it does not say 939 processes are alive, nor that 939 locks are held.

1. Count them: find ~/.dsh/sessions -name "session.lock" | wc -l, which the community found to be 939.
2. Look at the time distribution: the oldest is from a month earlier, and 09-26 through 09-28 alone contributed 89, 115, and 146. That staircase looks more like a launch loop than natural session growth.
3. Look at one file: zero bytes, identical to a live session's lock — and that is exactly why it "looks like a leak".
4. Look at real activity: only 3 workspace directories were touched that day, and only one session in them was active.
5. So the count has nothing to do with live processes, only with historical session count.

DSH plugin: What lock files really mean: the file stays, the lock may not

POSIX lock files are never deleted by design: the leftover file keeps a stable inode so later lockers can verify it is the same object; the kernel arbitrates ownership, not the file itself.

1. When the holder exits the kernel releases the lock but the file remains — that is "released", not "leaked".
2. Deleting the file changes the inode, so later lockers no longer see the same object.
3. Deleting a session lock that is in use abandons the whole point of its existence: mutual exclusion.
4. The community was blunt: such a "cleanup plugin" looks like housekeeping but behaves like a mutex bug.
5. If the file count is genuinely a problem, the right move is core providing a bounded directory or an explicit retention rule, not deleting at the point of use.

DeepSeek Harness: What "a row of Dock icons" means

It means every launch produced a new process and the system treats them as separate instances; what is missing is single-instance protection in the main process.

1. Rule out the install state first: ls -d /Applications/*Harness*.app | wc -l returns 1, a single app.
2. Then rule out extra pins: defaults read com.apple.dock persistent-apps | grep -c "com.deepseek.dsh" returns 1.
3. ~/Applications, /Users/Shared, and the desktop have no second copy, and there is no launcher on the desktop.
4. Check Info.plist: LSMultipleInstancesProhibited appears 0 times, and LSUIElement is absent too.
5. So LaunchServices starts a new process on every double-click, and each process takes a Dock icon.
6. The same root cause explains another old symptom: after quitting, you have to click the icon twice to reopen it.

DSH Plugin: Why both appear in one report

They share the trigger "repeated launch", but one is a runtime symptom and the other a filesystem leftover, and the handling is opposite.

That is also why the community reply only addresses the second half: mixing the two produces the false causal claim that deleting locks reduces Dock icons.

DeepSeek Harness: Thirty-second check: look at the two numbers separately

Two commands are enough: one counts the install state, one counts the runtime state; the install state is always 1, the runtime state changes, and neither is evidence of a lock leak.

# 1. install state: should be exactly 1
ls -d /Applications/*Harness*.app | wc -l
defaults read com.apple.dock persistent-apps | grep -c "com.deepseek.dsh"

# 2. runtime state: grows with the number of launches
find ~/.dsh/sessions -name "session.lock" | wc -l

# 3. single-instance declaration: without it, every launch is a new process
/usr/libexec/PlistBuddy -c "Print :LSMultipleInstancesProhibited" \
  "/Applications/DeepSeek Harness.app/Contents/Info.plist"

If the third reports Does Not Exist, it matches the community observation: no single-instance protection is declared, so repeated launches directly spawn new processes.

DSH plugin: What you can and cannot do

What you can do: reduce repeated launches and tidy desktop shortcuts. What you cannot do: delete locks or expect a plugin to fix single-instance behavior.

1. During observation, confirm the symptom first: double-click from the Dock over several days and record the icon count alongside find ... session.lock | wc -l.
2. Do not write a script to bulk-delete session.lock, especially not while the app is running.
3. To relieve icon pileup temporarily, quit all instances and reopen once; the Dock returns to a single icon.
4. Keep only one launch entry on the desktop and in the Dock so you do not double-click by accident.
5. The real fix requires the main process to call app.requestSingleInstanceLock() and exit when it fails, or to focus() the existing window in the second-instance event.
6. Alternatively declare LSMultipleInstancesProhibited in Info.plist so LaunchServices enforces it.
7. If the lock half is to improve, core should sweep locks whose holder PID is dead and which have no active writer at startup, rather than asking users to delete by hand.

Cautions

Do not clean a lock file to fix a Dock icon.

1. Do not read "0 bytes" as "empty file, safe to delete". Live and abandoned locks are indistinguishable at the file level, which is exactly why they cannot be cleaned casually.
2. Do not infer process count from icon count. Dock icons accumulate from launch history.
3. Do not expect a plugin to fix the Dock. The second launch happens before any plugin loads.
4. Record the version and OS. The community report is based on 0.2.0-rc.2, and behavior may change across versions.
5. Separate "many lock files" from "lock wait timeout". The latter is a different problem; its error only gives a path and should not be fixed by deleting files either.

If your Dock duplicates appear only when multiple app copies are installed, that is an install-state problem — remove the extra copies.See DeepSeek Harness desktop: no window, crash, EMFILE, 80s for the related case.