[sreedharsreeram]

What

The Supermemory API now serves the session endpoint unversioned at /session and keeps /v3/session as a deprecated alias (supermemoryai/mono#3626). status now looks up account info via /session first and falls back to /v3/session when the server predates it.

• src/cli.ts: getAccountInfo tries /session, then /v3/session.

Compatibility

• Older plugin builds keep working: the API still serves /v3/session.
• This build works against older self-hosted servers: /session 404s there, fetchJson returns null, and /v3/session is used. One extra request on old servers only.

Note: the repo's v5 migration chose explicit apiVersion selection "without failed-request fallback". This PR uses a fallback for this one read-only call; happy to switch it to the apiVersion gate if preferred.

Verification

• bun run typecheck, bun test (33/33).
• bun src/cli.ts status against a local API on the new path and against a shim that 404s /session: account details resolve in both; the shim log shows 404 GET /session then GET /v3/session.

🤖 Generated with Claude Code

[capy-ai]

Requesting a change in src/cli.ts:568-577: fetchJson collapses every non-2xx response, parse failure, and transport failure to null, so the new ?? retries /v3/session after 401/403, 429, 5xx, malformed JSON, and network errors—not only when an older server lacks /session. That can hide a broken canonical endpoint and doubles requests for failures that should remain failures.

Please preserve enough response information to fall back only for the explicit compatibility condition (normally 404; account for the scoped-key legacy 403 behavior described on supermemory#1839 if this client supports scoped keys). Add tests for canonical success, compatibility fallback, and a representative non-fallback failure.

[capy-ai]

P2 — Fall back only when /session is unsupported.

src/cli.ts:577 uses fetchJson(...) ?? fetchJson(...), but fetchJson returns null for every non-2xx response and every transport/parse failure. That means a 401, 429, 5xx, or network failure on /session triggers a second request to /v3/session; those paths share the same handler on the new API, so these failures do not identify an older server and can double load or obscure rate-limit behavior. Please preserve the response status and retry only the endpoint-compatibility case (while accounting for the legacy scoped-key 403 behavior in the API migration).