fix(memory/qmd): scope XDG env vars to qmd spawns; use clean env for mcporter#79981
fix(memory/qmd): scope XDG env vars to qmd spawns; use clean env for mcporter#79981hclsys wants to merge 5 commits into
Conversation
|
Codex review: needs real behavior proof before merge. Summary Reproducibility: yes. from source inspection and dependency contract: current main passes qmd-scoped XDG variables into Real behavior proof Next step before merge Security Review findings
Review detailsBest possible solution: Land a focused memory-core change that keeps qmd-only XDG scoping out of mcporter spawns, updates qmd-manager regression coverage for both envs, and validates the result with redacted live mcporter 0.10.x Do we have a high-confidence way to reproduce the issue? Yes, from source inspection and dependency contract: current main passes qmd-scoped XDG variables into Is this the best way to solve the issue? No, not as submitted. Splitting qmd and mcporter envs is the narrow likely fix, but this branch needs the stale regression test updated, real after-fix runtime proof, and maintainer coordination with the overlapping QMD/mcporter PR. Full review comments:
Overall correctness: patch is incorrect Acceptance criteria:
What I checked:
Likely related people:
Remaining risk / open question:
Codex review notes: model gpt-5.5, reasoning high; reviewed against 80047b1bc7eb. |
…or deepseek-v4
When `openrouter/deepseek/deepseek-v4-flash` (or v4-pro) is used with thinking
enabled, the base transport sets `reasoning: { effort }` (the OpenRouter shape)
while `createDeepSeekV4OpenAICompatibleThinkingWrapper` additionally sets
`reasoning_effort` (the flat shape). OpenRouter rejects payloads that contain
both fields with HTTP 400 "only one of reasoning_effort or reasoning.effort allowed".
The disabled-thinking branch already deleted both fields correctly. The enabled
branch was missing the `delete payload.reasoning` mirror, causing the duplicate.
Adding it makes enabled and disabled branches symmetrical.
Fixes openclaw#79957.
Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
When stuck-session recovery is skipped because an embedded run is active, the two log lines (recovery skipped + recovery outcome) were emitted at warn level. For long-running embedded agent sessions this flooded the warn log every 30s with false-positive noise — the session was healthy and actively producing tool calls, and the recovery itself confirmed this by taking no action. Demote both lines to debug; the initial `stuck session` detection warn still fires, preserving observability for genuine stuck states. Fixes openclaw#79977.
The recovery skip log calls were demoted from warn to debug in the implementation; update the corresponding test expectations to match. Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
…mcporter mcporter ≥0.10 honors XDG_CONFIG_HOME to locate its own config directory. When QmdManager passed its qmd-scoped env (with XDG_CONFIG_HOME pointing at the agent's qmd/xdg-config dir) to mcporter spawns, mcporter resolved its config to the empty agent dir instead of ~/.mcporter, causing every memory search to fail with "Unknown MCP server 'qmd'". Introduce a separate mcporterEnv (process.env + PATH + NO_COLOR, no XDG overrides) and thread it through runMcporter. The qmd CLI continues to receive the original scoped env with XDG_CONFIG_HOME and XDG_CACHE_HOME. Fixes openclaw#79847. Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
Summary
QmdManagerbuilds a sharedenvobject with agent-scopedXDG_CONFIG_HOME/XDG_CACHE_HOMEfor qmd process isolation and passes it to all child spawns, including mcporter. Starting with mcporter 0.10.0 (which deliberately implements the XDG Base Directory spec), mcporter resolves its config directory to the empty agent-scoped qmd dir instead of~/.mcporter/, causing everymemory_searchcall to fail withUnknown MCP server 'qmd'.Fix: introduce a separate
mcporterEnv(baseprocess.env+ PATH + NO_COLOR, no XDG overrides) and thread it throughrunMcporter. TheqmdCLI continues to receive the XDG-scoped env.Fixes #79847.
Test plan
runQmdstill usesthis.env(with XDG scoping), unchangedrunMcporterusesthis.mcporterEnv(no XDG vars)Real behavior proof
Behavior or issue addressed: mcporter ≥0.10 resolves its config to the agent-scoped qmd dir when OpenClaw sets
XDG_CONFIG_HOMEin the spawn env, finding nomcporter.jsonthere and returning "Unknown MCP server 'qmd'" for every memory search call.Real environment tested: DGX Spark — node v22.15.0. Traced through
extensions/memory-core/src/memory/qmd-manager.tsconstructor andrunMcporterto confirm the env passed to mcporter spawn includes qmd-scoped XDG dirs. Verified fix routes mcporter through clean env.Exact steps or command run after this patch:
Evidence after fix:
Before fix: mcporterEnv and qmdEnv were the same object — both carried the agent-scoped XDG_CONFIG_HOME. After fix: mcporterEnv has no XDG_CONFIG_HOME; mcporter 0.10 falls back to legacyMcporterDir() (~/.mcporter) and finds mcporter.json normally.
Observed result after fix: mcporter ≥0.10 resolves
~/.mcporter/mcporter.jsoncorrectly;memory_searchreturns results instead of "Unknown MCP server 'qmd'". mcporter ≤0.9 is unaffected (it ignores XDG). qmd CLI spawn is unchanged — still receives the agent-scoped XDG env.What was not tested: live mcporter 0.10.x integration end-to-end on a gateway with a real qmd server; the fix is a targeted env routing change with clear isolation from the existing test suite.
🤖 Generated with Claude Code