Skip to content

Host hyperia CLI is shadowed by the GUI binary — MCP CLI unreachable on the host #137

Description

@kordless

The MCP CLI (epic #122, cli/hyperia-mcp.ts, wrapper build/linux/hyperia -> cli.js) is complete and is exactly what n8 containers use (via HYPERIA_MCP_URL=http://host.docker.internal:9800). On the HOST it is not reachable:

  • .deb / .rpm: build/linux/after-install.tpl:23 symlinks /usr/local/bin/hyperia -> the Electron GUI binary (/opt/Hyperia/${executable}), NOT the wrapper. So hyperia status/run/--help hits app/index.ts:6 ('Hyperia does not accept any command line arguments') instead of the MCP CLI. (A prior template pointed at resources/bin/<exe> and was 'fixed' to the GUI binary because that path wasn't found — that swap is the regression.)
  • AppImage: app/utils/cli-install.ts:150 skips the symlink for AppImage, and an AppImage has no postinst — so no CLI link AND no chrome-sandbox perms fix (the latter likely also causing 'won't start' on fresh AppImage runs).
  • installCLI() only runs when the GUI launches, and races the postinst over the same /usr/local/bin/hyperia path.

Fix: point the host symlink at the packaged wrapper (/opt/${productFilename}/resources/bin/hyperia, robust fallback to the GUI binary if absent); make the wrapper resolve the Electron binary name robustly (hyperia vs legacy hyper); keep bare hyperia launching the GUI; provide an AppImage path (self-integrate the symlink, or document ln -s).

Acceptance: on a fresh .deb AND AppImage, hyperia doctor / hyperia status reach the LOCAL sidecar; hyperia --help / hyperia guide shows the CLI guide, not the app's arg-rejection.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions