[good first issue]🎯 Plugin reads platform-specific paths that do not exist on Linux

[fdefilippo]

Description

The plugin attempts to read several filesystem paths that only exist on specific platforms or configurations, causing repeated ENOENT errors on Linux servers.

Errors observed (Linux, running as root)

1. ENOENT: /Users/fh2497/Library/Application Support/Claude/claude_desktop_config.json — macOS-only Claude Desktop config path
2. ENOENT: /home/user/agent_memory/memory.json — hardcoded /home/user/ path
3. ENOENT: /home/user/data/agent_memory/config/user_profile.yaml — same issue

Impact

• Logs are spammed with error entries on every check
• Not a crash, but noisy

Expected behavior

The plugin should gracefully skip paths that do not exist (log at debug level, not error), and use os.homedir() with a configurable fallback.

Related

• Issue TypeError: Cannot read properties of undefined (reading 'resolveStateDir') on plugin register #89 (resolveStateDir crash) — same class of path-resolution bugs

Environment

• OS: Linux (Enterprise Linux 10.1)
• Plugin version: v0.3.5

[Maxwell-Code07]

Thanks for another thorough bug report! You're right, hardcoded platform-specific paths should use os.homedir() and graceful fallbacks. We'll look into cleaning this up. Appreciate you filing these issues!

[Maxwell-Code07]

We have selected this Issue as a 🎯 Good First Issue — perfect for new contributors to get started!

Task Details

Field	Content
Type	Bug
Difficulty	Low
Estimated Effort	4 days
Acceptance Criteria	1. Path checking supports Linux standard paths (~/.config/); 2. Silently skip or warn only once when path does not exist, no repeated ENOENT logs; 3. Add Linux test cases

Feel free to ask questions if you have any! 🚀

[fdefilippo]

Also know this one well — same root cause as #107, different symptom.

Root cause: The current path resolution logic is OS-agnostic by default, assuming paths that exist on macOS/Windows will exist on Linux. When they don't, fs.stat (or synchronous equivalent) fires an ENOENT error on every call, flooding logs.

The fix:

1. Platform-aware config paths — use os.platform() or process.platform to resolve the correct config directory:

   • Linux: process.env.XDG_CONFIG_HOME || path.join(os.homedir(), '.config', 'tencentdb-agent-memory')
   • macOS: path.join(os.homedir(), 'Library', 'Application Support', 'tencentdb-agent-memory')
   • Windows: process.env.APPDATA || path.join(os.homedir(), 'AppData', 'Roaming', 'tencentdb-agent-memory')

2. Silence the flood — if the resolved path does not exist, log a single warning on startup and store the result in a Set so subsequent calls to the same path skip silently:

   if (!pathExistsCache.has(resolvedPath)) {
     if (!fs.existsSync(resolvedPath)) {
       console.warn(`Config path ${resolvedPath} not found, using defaults`);
       pathExistsCache.add(resolvedPath);
     }
   }

3. Test cases — add a Linux CI test that intentionally uses a non-existent config path and confirms the warning appears only once with no ENOENT spam.

The actual memory operations need no changes — this is purely a bootstrap/path resolution fix.

[jiang1997]

I have joined the TencentDB Agent Memory Open Source Co-creation Program and claimed this issue.

[YOMXXX]

Triage note:

I checked the two open candidate fixes (#221 and #223) and did not select a canonical PR yet because both fail their focused config-path tests in my local environment.

Observed failures:

• fix(gateway): support platform config paths #221: COREPACK_ENABLE_AUTO_PIN=0 pnpm vitest run src/gateway/config.test.ts fails the XDG_CONFIG_HOME/tencentdb-agent-memory case, returning default port 8420 instead of the file port 9511.
• fix: support linux config paths with unified home resolution #223: COREPACK_ENABLE_AUTO_PIN=0 pnpm vitest run src/utils/config-paths.test.ts fails two loadGatewayConfig cases, returning default port 8420 instead of 9462 / 9461.

Likely area to revisit: platform-specific config lookup and the tests assumptions around Linux/XDG paths when run on non-Linux hosts. No duplicate/superseded decision from me for this issue until a candidate passes focused verification.

[YOMXXX]

Triage update: #443 is now the canonical fix for this issue.

Why #443:

• adds shared config-path helpers for safe optional file checks and HOME / USERPROFILE / OS home fallback
• loads Gateway config from XDG_CONFIG_HOME/tencentdb-agent-memory and ~/.config/tencentdb-agent-memory before the data-dir fallback
• reuses the same fallback behavior for OpenClaw hook-policy config lookup and state-dir resolution
• includes focused regression tests for XDG config, HOME .config, and USERPROFILE fallback behavior

Local verification:

• COREPACK_ENABLE_AUTO_PIN=0 pnpm vitest run src/utils/config-paths.test.ts (3/3 passed)
• COREPACK_ENABLE_AUTO_PIN=0 pnpm test (70/70 passed)
• COREPACK_ENABLE_AUTO_PIN=0 pnpm build
• git diff --check

Duplicate cleanup:

• fix(gateway): support platform config paths #221 and fix: support linux config paths with unified home resolution #223 have been marked as superseded by fix(config): support XDG config path fallbacks #443.

Note: local Node is v22.14.0, below the package engine >=22.16.0; commands completed successfully with the expected engine warning.