What's wrong
webcmd doctor can fail its browser connectivity check even when the managed Chromium binary under ~/.cloakbrowser/<version>/Chromium.app is completely intact and executable. The failure is a macOS LaunchServices (LS) database desync, not a broken install, and doctor doesn't detect or remediate it.
Repro / evidence
$ webcmd doctor
[OK] Daemon: running on port 9777 (v0.5.2)
[OK] Runtime: cloak connected (v0.4.5)
[FAIL] Connectivity: failed (Command failed: /usr/bin/open -g -n /Users/ng/.cloakbrowser/chromium-145.0.7632.109.2/Chromium.app --args ... about:blank
The application cannot be opened for an unexpected reason, error=Error Domain=NSOSStatusErrorDomain Code=-10827 "kLSNoExecutableErr: The executable is missing" ...)
But the binary itself is fine:
file Chromium.app/Contents/MacOS/Chromium → Mach-O 64-bit executable arm64- Running it directly (
.../Chromium --version) → prints Chromium 145.0.7632.109 and exits 0
codesign -dv → valid adhoc signature, no quarantine xattr
The failure is specifically in /usr/bin/open, which resolves .app bundles via the LaunchServices database rather than executing the path directly. kLSNoExecutableErr here means LS's cached record for that bundle path is stale/out of sync with the filesystem — not that the executable is actually missing.
Fix that works today (manual)
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -f "/path/to/Chromium.app"
This forces LS to re-scan and re-register the bundle. After running it, open on the same bundle succeeds immediately and webcmd doctor passes.
Why this likely happens
~/.cloakbrowser/<version>/Chromium.app is downloaded/unpacked by webcmd's own tooling (a script unzipping into a hidden dotfile directory), not installed via Finder/a .pkg. LaunchServices only reliably picks up new/changed bundles through specific triggers (background lsd rescans, Spotlight/mdimporter events, or an explicit lsregister call) — a script-driven unzip into a dotfile path can land outside those triggers, especially on a version bump/update where a previous bundle occupied a related path. In this instance, a .last_update_check file in the same directory was timestamped ~26 minutes before the failure, consistent with an update having just touched that tree.
Suggested fix
webcmd doctor (or the underlying connectivity check) should detect kLSNoExecutableErr specifically and either:
- Automatically run
lsregister -f on the managed Chromium bundle and retry once, or
- At minimum, print that exact remediation command in the
Issues: section instead of just reporting a generic connectivity failure.
Context
Hit this at the very start (Step 1: webcmd doctor) of a subagent building a new university-course-export adapter. It cost ~16 tool calls / ~1m45s of manual diagnosis (checking file validity, direct execution, code signature, then discovering lsregister -f was the fix) before recon could even start — and turned out to be moot in this case, since the adapter ultimately used Strategy.PUBLIC with browser: false and never needed the browser at all. Filed alongside #217, #218, #219 from the same session.
What's wrong
webcmd doctorcan fail its browser connectivity check even when the managed Chromium binary under~/.cloakbrowser/<version>/Chromium.appis completely intact and executable. The failure is a macOS LaunchServices (LS) database desync, not a broken install, anddoctordoesn't detect or remediate it.Repro / evidence
But the binary itself is fine:
file Chromium.app/Contents/MacOS/Chromium→Mach-O 64-bit executable arm64.../Chromium --version) → printsChromium 145.0.7632.109and exits 0codesign -dv→ valid adhoc signature, no quarantine xattrThe failure is specifically in
/usr/bin/open, which resolves.appbundles via the LaunchServices database rather than executing the path directly.kLSNoExecutableErrhere means LS's cached record for that bundle path is stale/out of sync with the filesystem — not that the executable is actually missing.Fix that works today (manual)
This forces LS to re-scan and re-register the bundle. After running it,
openon the same bundle succeeds immediately andwebcmd doctorpasses.Why this likely happens
~/.cloakbrowser/<version>/Chromium.appis downloaded/unpacked by webcmd's own tooling (a script unzipping into a hidden dotfile directory), not installed via Finder/a.pkg. LaunchServices only reliably picks up new/changed bundles through specific triggers (backgroundlsdrescans, Spotlight/mdimporterevents, or an explicitlsregistercall) — a script-driven unzip into a dotfile path can land outside those triggers, especially on a version bump/update where a previous bundle occupied a related path. In this instance, a.last_update_checkfile in the same directory was timestamped ~26 minutes before the failure, consistent with an update having just touched that tree.Suggested fix
webcmd doctor(or the underlying connectivity check) should detectkLSNoExecutableErrspecifically and either:lsregister -fon the managed Chromium bundle and retry once, orIssues:section instead of just reporting a generic connectivity failure.Context
Hit this at the very start (Step 1:
webcmd doctor) of a subagent building a new university-course-export adapter. It cost ~16 tool calls / ~1m45s of manual diagnosis (checking file validity, direct execution, code signature, then discoveringlsregister -fwas the fix) before recon could even start — and turned out to be moot in this case, since the adapter ultimately usedStrategy.PUBLICwithbrowser: falseand never needed the browser at all. Filed alongside #217, #218, #219 from the same session.