[Bug] macOS: Dock accumulates duplicate DeepSeek Harness icons — no single-instance lock, and 939 stale session.lock files never reclaimed

[Xaiver03]

Environment

Item	Value
DSH Desktop	0.2.0-rc.2 (CFBundleVersion = 0.2.0-rc.2)
Bundle ID	com.deepseek.dsh
OS	macOS (Darwin, arm64)
Install	single copy at /Applications/DeepSeek Harness.app
Launch method	double-click from Desktop/Dock only — never CLI, never a second bundle

Summary

Two related defects on macOS:

1. The Dock fills up with many identical DeepSeek Harness icons, even though exactly one app bundle is installed and only one pinned Dock entry exists.
2. 939 stale session.lock files have accumulated under ~/.dsh/sessions/ and are never reclaimed.

The two are likely the same root cause: the app has no single-instance guard, so repeated launches create independent processes, each holding its own session lock. The lock files then outlive the processes.

Evidence

1. Only one bundle, only one Dock pin

$ ls -d /Applications/*Harness*.app | wc -l
1

$ defaults read com.apple.dock persistent-apps | grep -c "com.deepseek.dsh"
1

There is no second copy under ~/Applications, /Users/Shared, or the Desktop. The Desktop contains no launcher for DSH. So the multiplicity in the Dock is not pins and not duplicate bundles — it is runtime state.

2. No single-instance protection in the bundle

Contents/Info.plist does not declare:

LSMultipleInstancesProhibited   → absent (0 occurrences)
LSUIElement                     → absent

Because LSMultipleInstancesProhibited is absent, LaunchServices happily starts a fresh process for every open/double-click instead of activating the existing window. This also matches the previously reported symptom in discussion #9078 ("退出后需点击两次图标才能重新打开").

3. Session locks are never cleaned up

$ find ~/.dsh/sessions -name "session.lock" | wc -l
939

Distribution by date of the oldest surviving lock:

Date	Stale session.lock count
2026-09-23	(earliest)
2026-09-26	89
2026-09-27	115
2026-09-28	146
2026-09-29	31
2026-09-30	11
2026-10-11	10
2026-10-13	23
2026-10-16	39
2026-10-18	42
2026-10-20	22
2026-10-21	21
2026-10-22	7
2026-10-23	4

Locks from 2026-09-23 — a month old — are still present. Note the step change on 09-26 → 09-28 (89 → 115 → 146), which is consistent with a launch loop rather than organic session churn.

A sample of the current lock for a live session:

~/.dsh/sessions/--<workspace-A>--/session-<uuid>/session.lock   (0 bytes, live)

Zero-byte locks are indistinguishable from abandoned ones by inspection, which is what makes them unrecoverable in practice (cf. discussion #7158 "Writer-lock timeout error names only the path, leaving an orphan lock unrecoverable in practice").

4. Actual activity does not justify the icon count

Only 3 workspace session directories were touched on 2026-10-23 (today):

10-23 13:48   sessions=1    ...<workspace-A>--      ← the only live session
10-23 12:07   sessions=30   ...<workspace-B>--
10-23 11:40   sessions=154  ...<workspace-C>--

Everything else is dated 10-22 or earlier — historical session files, not live sessions. A single active session is producing a Dock with many icons.

Expected

• Launching the app while it is already running should focus the existing window, not add another Dock tile.
• Terminated sessions should release/remove their session.lock.
• The Dock should show at most one icon per running instance, and ideally exactly one for the whole app.

Actual

• The Dock accumulates one tile per launched process (observed: a long row of identical icons from a single install with a single pin).
• 939 session.lock files persist indefinitely across app quits and restarts.

Suggested fixes

1. Add a single-instance guard in the main process (app.requestSingleInstanceLock() and quit/bail when not acquired, or second-instance → focus()). This is the primary fix for the Dock symptom.
2. Optionally set LSMultipleInstancesProhibited in Info.plist so macOS enforces it at the LaunchServices layer as well.
3. Reclaim session.lock on startup: sweep locks whose owning PID is dead (and whose session has no live writer), and delete them. 939 accumulated files indicate this never runs.
4. Consider LSUIElement or an explicit Dock policy if N windows are intentional — a single Dock tile with multiple windows would match user expectations better than N tiles.

Related discussions (checked, not duplicates)

• [issue] DSH 桌面端反馈：退出后需点击两次图标才能重新打开 #9078 — 退出后需点击两次图标才能重新打开 (same missing-lock root cause, different symptom)
• [Feature] Document an isolated Desktop launch for native UI acceptance (userData, instance lock, profile) #9823 — Document an isolated Desktop launch (userData, instance lock, profile)
• [Bug] Live sessions have no retention policy: heap grows with opened-session count and OOMs at any heap cap (128 GB host, measured per-session costs) #6889 — Live sessions have no retention policy (unbounded growth, analogous to lock accumulation)
• Writer-lock timeout error names only the path, leaving an orphan lock unrecoverable in practice #7158 — orphan writer-lock unrecoverable in practice
• [Bug] Windows: boot-time corpus scan exhausts process fd limit (EMFILE) and leaves a permanent empty .lock that blocks every later boot #9653 — Windows: permanent empty .lock blocking later boot (Windows analogue of the stale-lock issue)

Reproduction sketch

1. Install DSH Desktop 0.2.0-rc.2 (single copy).
2. Confirm one Dock pin: defaults read com.apple.dock persistent-apps | grep -c com.deepseek.dsh → 1.
3. Launch the app repeatedly over days (double-click from Dock/Desktop).
4. Observe: Dock shows many identical DSH tiles, while only one or two sessions are actually active.
5. Observe: find ~/.dsh/sessions -name session.lock | wc -l grows monotonically and never shrinks.

Note on collection limits

ps, osascript (System Events), and launchctl list were all unavailable in the sandboxed collection environment, so a direct process count could not be captured. The Dock-tile multiplicity is therefore established from the screenshot plus the absence of any pin/bundle duplication and the absence of LSMultipleInstancesProhibited; the lock-file count is a direct filesystem measurement.

[argszero]

Two readings from the source, in case anyone acts on the second half of this report:

1. The session.lock files are not stale, and a reclaimer would be harmful. The lease contract documents the POSIX lock file as deliberately never removed — the surviving file keeps the stable inode that later lockers verify against, and the kernel, not the file's existence, is what arbitrates ownership. A zero-byte file whose holder has exited is a released lock, not a leaked one. So 939 files means 939 sessions were materialized in that workspace; it does not mean 939 processes are alive or that 939 locks are held. Removing a live session's lock to tidy the directory forfeits the exclusion it exists to provide, which is why I would not accept a reclamation plugin for this half: it looks like cleanup and behaves like a mutex bug. If the count itself is unwanted, the fix is a bounded directory or a documented retention rule in the core, not deletion at the point of use.

2. The Dock duplicates are a separate defect, and a real one: with no single-instance guard, every launch is a new process as far as the system is concerned. That is a core decision, not something a plugin can supply — the second launch has already happened by the time any extension is loaded.