Desktop app exits silently with exit code 3 when it cannot create its user-data files (no dialog, no log)

[PHSchr3ck3]

Environment

• DSH Desktop 0.2.1-rc.5, Windows 11 x64
• Per-user install: %LOCALAPPDATA%ProgramsDeepSeek Harness

Symptom

The desktop app stopped starting entirely. Double-clicking the exe produced no window, no dialog, no log entry and no files under %APPDATA%@deepseek-aidsh-desktop; the process exited immediately with exit code 3. --dump-config is refused for the managed desktop profile, so there was no user-facing way to find out what failed.

Evidence

Starting the exe with --enable-logging --log-file=<writable path> produced:

ERROR:chrome�rowserprocess_singleton_win.cc:318] Lock file can not be created: Zugriff verweigert (0x5)
Histogram: Chrome.ProcessSingleton.CreateLockFileWithTimeout.ErrorCode recorded 1 samples
5  -O   (1 = 100.0%)

The install folder carried this ACL at the time (Jeder = Everyone):

DeepSeek Harness  Jeder:(CI)(DENY)(DC)
                  S-1-4-1050771962-1020670054:(OI)(CI)(W,D,DC)
                  NT-AUTORITAETSYSTEM:(I)(OI)(CI)(F)
                  VORDEFINIERTAdministratoren:(I)(OI)(CI)(F)
                  PC<user>:(I)(OI)(CI)(F)
                  Verbindliche BeschriftungNiedrige Verbindlichkeitsstufe:(OI)(CI)(NW)

With that ACL in place the app could read anywhere but write only inside its own install folder. Verified by running the same binary with ELECTRON_RUN_AS_NODE=1 and a script writing to several paths: %USERPROFILE%, %APPDATA%, %TEMP% and ~/.dsh all returned EPERM, while the install folder succeeded.

Control tests:

• Same tree copied to a clean folder -> starts normally, creates cordis.yml and the Chromium profile.
• After removing the deny ACE and the foreign SID and resetting the integrity label to Medium (icacls ... /setintegritylevel (OI)(CI)M /T) -> the original install starts again.

Likely trigger

A third-party sandbox/security tool appears to have applied that ACL to the folder, so the permission state itself is environmental. The DSH-side bug is that this state fails completely silently.

Request

1. Surface startup failures: show a dialog and/or write a startup log entry when the user-data directory, the single-instance lock file or the profile composition fails, including the affected path and the OS error code.
2. Never exit with code 3 without any log artifact. A log written to a fallback location such as %TEMP% would have made this diagnosable in seconds.
3. Optionally detect a Low-integrity/AppContainer ACL on the install folder and warn the user instead of dying.

Workaround for other users

icacls "<install dir>" /remove:d "*S-1-1-0" /T /C
icacls "<install dir>" /remove:g "*S-1-4-*" /T /C
icacls "<install dir>" /setintegritylevel (OI)(CI)M /T /C

[PedroCostinha]

Hi! The ACL evidence and successful clean-folder test make this a useful case for improving early startup diagnostics.

One important consideration is that the application may fail before its normal logging system becomes available.

I would suggest checking write access to the required user-data and Chromium profile locations before initializing the main application services.

If this check fails, the launcher could report the affected path, Windows error code, and process exit reason through an early diagnostic channel or fallback log.

I would avoid automatically removing restrictive ACL entries, since they may have been intentionally applied by endpoint security software.

A regression test could launch the application under a restricted test account and verify that a permission failure produces a useful diagnostic instead of a silent exit.

This would preserve the existing security boundary while making the failure much easier to investigate.