An unparseable ~/.rmapi aborts every command even when a valid config exists at %APPDATA%\rmapi\rmapi.conf (Windows)

[AriJGinsberg]

Summary

On Windows, if a file exists at ~/.rmapi (%USERPROFILE%\.rmapi) that isn't a valid rmapi config, every rmapi command aborts at startup with a failed to parse error — even when a valid, authenticated config is already present at %APPDATA%\rmapi\rmapi.conf. rmapi hard-fails on the legacy file instead of falling back to the platform config (or to RMAPI_CONFIG).

This is easy to hit in practice because other tools use ~/.rmapi as a token location. In my case a reMarkable MCP server writes a raw JWT to ~/.rmapi (a different format from rmapi's config) and recreates it on every call, so rmapi breaks repeatedly until the file is removed or RMAPI_CONFIG is set.

Environment

• rmapi v0.0.34
• Windows 11, running rmapi.exe from Git Bash
• Real config (valid, paired) at C:\Users\<user>\AppData\Roaming\rmapi\rmapi.conf

Reproduction

# 1. Have a normal, working rmapi (config at %APPDATA%\rmapi\rmapi.conf)
rmapi ls /            # works

# 2. Put any non-config content at ~/.rmapi
echo "some-raw-token-blob" > ~/.rmapi

# 3. Now every command aborts:
rmapi ls /
# ERROR: 2026/... config.go:77: failed to parse C:\Users\<user>\.rmapi

Expected

rmapi should not be bricked by an unparseable legacy ~/.rmapi when a valid config exists at the platform default. Reasonable options:

1. If ~/.rmapi fails to parse, fall through to the platform config dir (%APPDATA%\rmapi\rmapi.conf on Windows) / RMAPI_CONFIG instead of aborting.
2. At minimum, make the error actionable — name the offending file and mention that RMAPI_CONFIG can override it or the file can be removed.

Actual

config.go:77: failed to parse C:\Users\<user>\.rmapi, and the command exits. Nothing runs until the file is deleted or overridden.

Workaround (for anyone who finds this)

Point RMAPI_CONFIG at the real config — rmapi then ignores the stray ~/.rmapi:

RMAPI_CONFIG="%APPDATA%\rmapi\rmapi.conf" rmapi ls /   # works even with the junk ~/.rmapi present

(Confirmed on v0.0.34: same junk ~/.rmapi on disk, RMAPI_CONFIG set → clean ls.)

Happy to open a PR for option 1 or 2 if you have a preference on the approach. Thanks for maintaining this fork!

[AriJGinsberg]

Confirming this with a concrete repro + cause, since it bit me too.

Trigger: the remarkable-mcp server (uvx remarkable-mcp) writes a raw bearer-token file to ~/.rmapi as a side effect of starting up. After that, every rmapi.exe invocation on Windows tries to parse ~/.rmapi, chokes on it (it's a raw token, not the expected config format), and hard-aborts — even though a perfectly valid config exists at %APPDATA%\rmapi\rmapi.conf.

Workarounds that work today:

• set RMAPI_CONFIG=%APPDATA%\rmapi\rmapi.conf (or export RMAPI_CONFIG) to force the good config, or
• delete/move ~/.rmapi.

Suggested fix: on Windows, prefer %APPDATA%\rmapi\rmapi.conf when it exists, and/or don't fail hard on an unparseable ~/.rmapi — fall back to the platform config path instead of aborting the whole command.