Skip to content

Windows: CLI discovery cannot succeed, and the README has no Windows install path #5

Description

@allenliang2022

Summary

On Windows the plugin can never find the Mnemon CLI on its own, and the README offers no Windows install path. The resulting error reads like a user mistake, when the actual cause is that upstream Mnemon publishes no Windows binary at all.

Three separable problems, in decreasing severity.

1. CLI discovery cannot succeed on Windows

findMnemonCommand resolves in this order: config.cliPath$MNEMON_CLI_PATH → a $PATH scan → COMMON_CLI_PATHS. The $PATH scan does handle Windows correctly (mnemon.exe / mnemon.cmd / mnemon), but the final fallback cannot:

const COMMON_CLI_PATHS = [
  "~/.local/bin/mnemon",
  "/opt/homebrew/bin/mnemon",
  "/usr/local/bin/mnemon",
  "/usr/bin/mnemon",
]

All four are Unix paths, and none carries a .exe suffix. A Windows user who installed the CLI anywhere other than a $PATH directory gets:

Mnemon 尚未就绪
failed to launch mnemon ("mnemon"): spawn mnemon ENOENT.
Install Mnemon and ensure "mnemon" is on PATH, or set dsh-mnemon.cliPath.

Suggested candidates for the Windows branch:

"%USERPROFILE%\\go\\bin\\mnemon.exe",          // go install — currently the only Windows route
"%LOCALAPPDATA%\\Programs\\mnemon\\mnemon.exe",
"%ProgramFiles%\\mnemon\\mnemon.exe",

go install deserves first place because, as of Mnemon v0.2.2, it is the only way to obtain the binary on Windows.

2. The README has no Windows install path

"Start in five minutes → 1. Install Mnemon" lists exactly two routes:

brew install --cask mnemon-dev/tap/mnemon    # macOS
go install github.com/mnemon-dev/mnemon@latest  # macOS / Linux via Go

The Go line works on Windows too, but it is labelled "macOS / Linux", so a Windows reader has no reason to try it. Meanwhile the upstream release publishes only darwin_{amd64,arm64} and linux_{amd64,arm64} — there is no Windows archive to download.

Verified working on Windows:

go version go1.26.5 windows/amd64
go install github.com/mnemon-dev/mnemon@latest   # resolves v0.2.2
# -> %USERPROFILE%\go\bin\mnemon.exe (20,289,536 bytes)

mnemon status then creates and reads the store normally, and mnemon_status through this plugin reports healthy: true, commandFound: true, with a healthy default store.

Mnemon's Windows build was restored upstream in mnemon-dev/mnemon#103, two minutes before v0.2.2 was tagged; the release matrix simply was not updated with it. I have filed that separately against mnemon-dev/mnemon. Until an artifact ships, a Windows section here saying "build it with go install, then point cliPath at %USERPROFILE%\go\bin\mnemon.exe" would resolve the whole class of report.

3. Setting cliPath in a profile patch silently drops every packaged default

This one costs configuration rather than time, and it is easy to hit while following the error message's own advice.

The bundle cordis.patch.yml ships ten values:

config:
  routingGuidance: true
  displayMode: sidebar
  lifecycleEnabled: true
  recallMode: guided
  writebackMode: guided
  idleReviewMs: 30000
  tabEnabled: true
  writeEnabled: true
  timeoutMs: 10000
  defaultRecallLimit: 10

A profile's own patch entry replaces that config block rather than merging into it. Writing only what the error message asks for:

- id: mnemon
  config:
    cliPath: "C:/Users/liang/go/bin/mnemon.exe"

composes to a row whose config is only cliPath — confirmed by dumping the composition. Every other key falls back to its schema default, which is not necessarily the packaged value, and nothing warns about it. I only noticed because I dumped the composition before restarting.

The header comment already says "The profile's own final patch may replace this config row", which is literally accurate, but a reader looking for how to set one field will not read that as "and you will lose the other ten". Two cheap mitigations:

  • state the replacement semantics explicitly in the README next to the cliPath guidance, with a copy-paste block that keeps the packaged defaults; or
  • prefer $MNEMON_CLI_PATH, or a user-settings entry, as the documented way to point at a binary, so the common case never touches the patch layer.

Environment

  • Windows 11, amd64
  • dsh-mnemon 0.1.4, DeepSeek Harness 0.1.0-rc.5
  • Mnemon v0.2.2 built locally via go install (Go 1.26.5)
  • Working configuration after the fix: cliPath plus the ten packaged defaults copied back in verbatim

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