Skills/Desktop Control always show "Not installed": installer writes ~/.agents/ but status checker reads ~/agents/ (no dot)

[DLME2024]

Summary

In v5.6.1 (and current HEAD, e12376c), the Settings/Agents Hub status checks look for skills and hooks under ~/agents/ (no dot), but gxserver agent-skills install writes them to ~/.agents/ (with dot). Since nothing in the codebase ever creates ~/agents/, every skill / hook / Desktop Control Runtime status permanently shows Not installed even though installation succeeds — clicking Install works, writes the files, and the badge never changes. Cua Driver + skill installs also re-run on every attempt because of this.

Where

Checker (no dot) — native/sidebar/native-sidebar.tsx:

• L22441: const home = os.homedir();
• L22449–22460: path.join(home, "agents", "skills", "ghostex-…", "SKILL.md") for all six bundled skills
• L39687: agents-hub root: path.join(home, "agents", "skills")
• L39839: const hooksRoot = path.join(home, "agents", "hooks");

Installer (with dot) — gxserver-rs/src/agent_skills.rs:

• L180 / L201: paths.home_dir.join(".agents").join("skills")

Repro (macOS, Ghostex 5.6.1 from the homebrew cask)

1. Fresh machine state (no ~/agents or ~/.agents).
2. Settings → install any bundled skill or Desktop Control.
3. Files appear in ~/.agents/skills/<skill>/SKILL.md (plus per-agent symlinks, e.g. ~/.claude/skills/).
4. Status still reports Not installed; desktopControlReady stays false because computerUseSkillInstalled reads the non-existent ~/agents/… path.

Workaround

ln -s ~/.agents ~/agents — after which all statuses report Installed using the app's own detection logic.

Happy to provide more environment details if useful. Diagnosed with Claude Code by tracing the shipped native-sidebar.js status script against the repo source.

[DLME2024]

Follow-up: found a second, independent reason the Cua Permissions row shows Permission Status Unknown even after the skills-path issue is worked around.

1. which("cua-driver") never finds the driver from the app

The status probe only checks permissions inside if (cuaDriverPath) where cuaDriverPath = which("cua-driver") against the app process's PATH. The trycua installer links the CLI at ~/.local/bin/cua-driver, which is not on a GUI app's launchd PATH — so the permission check silently never runs. Note the installed check has a /Applications/CuaDriver.app fallback, but the permissions check doesn't; falling back to /Applications/CuaDriver.app/Contents/MacOS/cua-driver would fix this.

2. parseCuaPermission can't parse cua-driver 0.7.1 output

Even when the binary is found, native/sidebar/native-sidebar.tsx's parseCuaPermission regex expects text like Accessibility: granted, but cua-driver check_permissions '{"prompt": false}' in the current release (0.7.1) emits JSON only:

{ "accessibility": true, "screen_recording": true, ... }

Both labels parse to null → the badge is permanently Permission Status Unknown regardless of actual TCC state. (trycua HEAD builds a ✅ Accessibility: granted. summary for the MCP tool result, but the 0.7.1 CLI prints only the JSON payload.)

Verified on macOS 26 (Darwin 25.2.0), Ghostex 5.6.1, cua-driver 0.7.1: with the driver on the app's PATH and both permissions actually granted (confirmed via the driver daemon's own identity), the row still shows Unknown due to the parse mismatch.

[DLME2024]

Correction/final root cause on the Permission Status Unknown badge — it turns out to be unfixable by any driver output in 5.6.1:

parseCuaPermission lives inside the String.raw status-script template, and its regex is double-escaped. The executed script contains:

new RegExp(label + "\\\\s*:\\\\s*([^\\\\n.]+)", "i")

which evaluates to the pattern Accessibility\\s*:\\s*([^\\n.]+) — i.e. it requires a literal backslash after the label, and the capture class [^\\n.] excludes the letter n (case-insensitively, due to the i flag). Since granted, denied, and missing all contain n, the parser can never return true or false for any conceivable output — it always returns null, so the badge is permanently Permission Status Unknown for every user on this build.

Verified by running the shipped script verbatim: parseCuaPermission("Accessibility: granted", "Accessibility") → null.

Fix: de-escape to \\s/\\n levels appropriate for the String.raw context (or sidestep regex entirely by parsing the driver's JSON output, per my previous comment — that's the more robust option since cua-driver 0.7.1 emits JSON anyway).

[maddada]

Hey I believe we spoke on the discord about this?
I'm sorry I'm busy with porting the app to gpui version so it works on linux and windows, not just macOS but this issue is top of my list after that.
Thank you again for the great report 🙏🏻