Repository navigation
mcpx: codedb and fff entries in .mcpx.json still use /home/user absolute paths #864
Description
Follow-up to #863 (which made the desktop-commander entry portable).
The same portability wart remains for two other entries in the tracked project config .mcpx.json:
codedb:command: "/home/user/bin/codedb"fff:command: "/home/user/.local/bin/fff-mcp"
These absolute paths only resolve on machines whose home is /home/user. Because mcpx project scope overrides user scope, a machine with a different home directory cannot shadow them with working user-level entries — the broken project entries win and the servers fail to start.
Observed on the Muse sandbox (home /home/hatch), merged project view via mcpx status:
server "codedb": start /home/user/bin/codedb: fork/exec ...server "fff": start /home/user/.local/bin/fff-mcp: fork/exec ...
Possible directions (not prescribed): portable npx-style commands like the rest of the file where a published package exists, a PATH-relative command name, or an env-substituted path if mcpx config supports it. Any change should keep the laptop (home /home/user) working unchanged in behavior.
Acceptance criteria
- The
codedbandfffentries in the tracked.mcpx.jsonno longer hard-code/home/userabsolute paths; they resolve on machines with a different home directory (verified on the Muse sandbox, home/home/hatch, viamcpx statuswith no fork/exec errors for these servers). - Behavior on the laptop (home
/home/user) is unchanged: both servers still start and respond. - The chosen mechanism (PATH-relative name, published package command, or env substitution) matches the portability approach already used for the
desktop-commanderentry in mcpx: make desktop-commander entry portable (npx form) #863.
Activity
dezren39 commentedon Oct 26, 2026
Intake review
Fleet monitor intake pass (2026-10-25 run). Acceptance criteria appended to the body this pass (original body preserved verbatim above it).
Still live — verified this run: No sibling issue or PR found addressing the
codedb/fffentries (search this run: none); #863 fixed only thedesktop-commanderentry, and this is its named follow-up.Related: #863 (the desktop-commander portability fix — its mechanism is the precedent to match). Cross-repo note: mcpx also lives in dezren39/nix, but this issue is specifically about this repo's tracked
.mcpx.jsonproject entries, so it stays single-repo per the fleet's one-change-one-issue rule; if the fix turns out to be an mcpx config-mechanism change (e.g. env substitution support), that part would be a set handled from the origin issue.Notes / suggested approach: Because project scope overrides user scope in mcpx, these two entries are actively broken on any non-
/home/usermachine (observed fork/exec failures on the Muse sandbox, home/home/hatch). Prefer, in order: a PATH-relative command name if both tools are reliably on PATH, a published-package command like the rest of the file where one exists, or env substitution if mcpx supports it. Verify on both homes (sandbox/home/hatchand laptop/home/user) per the criteria.Risks: Low. Only real risk is picking a mechanism that resolves differently under the systemd/user-session PATH vs an interactive shell — the
mcpx statuscheck on each machine covers it.dezren39 commentedon Nov 1, 2026
🤖 Agent note · picked up
.mcpx.jsonstill use /home/user absolute paths on current main; route the fix.dezren39 commentedon Nov 1, 2026
🤖 Triage verdict — CONFIRMED, with one dormancy nuance and one scope expansion (queue task 2277, lane B)
Verified on current main b56ccda (
.mcpx.jsonread fromorigin/main):fff— confirmed, active. Line 13 (activemcpServers):"command": "/home/user/.local/bin/fff-mcp". Project scope overrides user scope, so this breaks fff on every machine whose home isn't/home/user— the failure mode in the issue stands.codedb— path confirmed, impact dormant. Line 89 still has"command": "/home/user/bin/codedb", but the entry now sits underdisabledMcpServers— parked there by 387a0cf ("mcpx: park the codedb server under disabledMcpServers", Drew 2026-10-29). It cannot fail to start while parked; the wart returns the moment it's re-enabled, so it stays in the fix scope at lower urgency. Its parked state is Drew's call and the fix does not re-enable it.fff-nix(lines 79–80) andfff-worktree(lines 83–84) are active entries with the same absolute command plus absolute-path args —/home/user/codeand/home/user/.local/share/opencode/worktree. Those args name machine-specific roots, so they're in the fix packet too.exec.Command, so bare command names resolve through PATH exactly like the existingnpx/goentries (the mcpx: make desktop-commander entry portable (npx form) #863 desktop-commander precedent, 789b7f9); there is no$HOME/tilde expansion of server command/args inpkgs/mcpx/internal/config, so "just write$HOME/..." is not an available spelling today.Remainder, routed as one scoped small_fix packet (enqueued as task 4865, packet-864-fix.json): bare-name commands for
fff/codedbafter PATH verification in the daemon environments;fff-nix/fff-worktreeremoved from the tracked project config (machine-specific roots belong in user scope) unless a portable root spelling is proven; grep-verified zero/home/userin.mcpx.json; file stays biome/treefmt-clean. No mcpx expansion machinery, no codedb re-enable.13 remaining items
dezren39 commentedon Nov 1, 2026
Parked (task 4865) with the mechanism verified — one open question remains before editing
.mcpx.json:desktop-commandermechanism wasnpx(a published package exists); none exists forfff-mcp/codedb, and the file's own precedent for local tools is bare names (go). Verified resolvable: sandbox has/home/hatch/.local/bin/fff-mcpand/home/hatch/bin/codedb; laptop login PATH resolves/home/user/.local/bin/fff-mcp(codedbis not on the laptop login PATH, but its entry is disabled/dormant).fff-nix(/home/user/code) andfff-worktree(/home/user/.local/share/opencode/worktree) — mcpx's server spawn does no env or tilde expansion (checkedpkgs/mcpx/internal: only a dashboard dir param expands~).~/codeand~/.local/share/opencodeexist on both machines, so~/…args are right iffff-mcpexpands them itself — that needs one test before changing config that must keep working unchanged on the laptop.Resume: run that
fff-mcptilde test, then apply bare commands + the verified arg form in one PR.dezren39 commentedon Nov 1, 2026
🤖 Agent note · picked up
dezren39 commentedon Nov 1, 2026
🤖 Agent note · blocked
mcpx serve, PID 3095268) has a PATH that omits/home/user/.local/binand/home/user/bin;fff-mcpis installed only at/home/user/.local/bin/fff-mcp. Therefore the packet-required barefff-mcpcommand does not resolve for this daemon. No tracked config edit or workaround was made, per the packet’s explicit stop condition.fff-mcpresolvable from the daemon PATH or revise the packet to authorize another portable invocation..mcpx.jsonchanges.developing-today commentedon Nov 3, 2026
agent-note:v1
state: reviewed (coverage loop-back)
Coverage pass 2026-11-03, loop-back review: this issue was re-reviewed (drift / overlap / already-handled / stale / blockers / ordering) so every open issue in the four repos is reviewed and in the system. Verdict: still live; in the system as task 4865 (small_fix, blocked, priority 50) in repo-health-code-pilot. Labels audited and synced. If it is already handled at current main, its triage closes it with evidence; if oversized, the triage files the split; blockers belong on this issue.
Found via: coverage loop-back 2026-11-03