Summary
After a batch of move calls over MCP, 7 of ~40 moved documents were later written to disk as 0-byte files by the server's own auto-save (attributed to OpenKnowledge (service), with no agent or human edit in between). The content was only recoverable from project git history.
Environment
ok CLI 0.68.3 (latest on npm is 0.74.1 — not yet retested there)- Windows 11, project with GitHub-substrate auto-save commits
- Client: Claude Code over MCP
What happened
- An agent restructured a project (~40 docs) using the MCP
move tool, e.g. 12-video-and-content-creation/projects/hermes-remotion-setup → archive/hermes-remotion-setup. Moves completed at 22:52–22:54 local time; the shadow history shows the attributed rename: entry for each.
- At 22:59 and 23:03,
wip: auto-save entries by OpenKnowledge (service) (empty docs list) appear in the shadow history, and the matching project git auto-save commits show the moved files going to 0 bytes (e.g. archive/hermes-remotion-setup.md | 87 -----).
- No
write/edit targeted those docs between the move and the truncation.
Shadow history for one affected doc (trimmed):
2026-09-15T22:53:01 claude-code rename: 12-video-and-content-creation/projects/hermes-remotion-setup -> ...
2026-09-15T22:59:37 OpenKnowledge (service) wip: auto-save (docs: [])
2026-09-15T23:03:39 OpenKnowledge (service) wip: auto-save (docs: [])
Affected: 7 docs, all moved in the same session (pure renames and renames with link rewrites both affected). ~33 other docs moved in the same batch were fine. One doc that was moved and then immediately edited by the agent was not truncated.
Expected
A moved document keeps its content; auto-save never persists an empty body for a doc that had content on disk.
Suspicion (unverified)
The server may hold an empty/unhydrated Y.Doc under the new docName after a move, which the auto-save later flushes over the file. ~/.ok/logs only contains cli command started lines, so I couldn't confirm server-side.
Workaround
Checkpoint before batch moves; after moving, check for find . -name '*.md' -size 0 and restore from git (git show <commit>^:<path>) via write.
Related, possibly: #1094 (silently discarded writes).
🤖 Generated with Claude Code
Summary
After a batch of
movecalls over MCP, 7 of ~40 moved documents were later written to disk as 0-byte files by the server's own auto-save (attributed toOpenKnowledge (service), with no agent or human edit in between). The content was only recoverable from project git history.Environment
okCLI 0.68.3 (latest on npm is 0.74.1 — not yet retested there)What happened
movetool, e.g.12-video-and-content-creation/projects/hermes-remotion-setup→archive/hermes-remotion-setup. Moves completed at 22:52–22:54 local time; the shadow history shows the attributedrename:entry for each.wip: auto-saveentries byOpenKnowledge (service)(emptydocslist) appear in the shadow history, and the matching project git auto-save commits show the moved files going to 0 bytes (e.g.archive/hermes-remotion-setup.md | 87 -----).write/edittargeted those docs between the move and the truncation.Shadow
historyfor one affected doc (trimmed):Affected: 7 docs, all moved in the same session (pure renames and renames with link rewrites both affected). ~33 other docs moved in the same batch were fine. One doc that was moved and then immediately edited by the agent was not truncated.
Expected
A moved document keeps its content; auto-save never persists an empty body for a doc that had content on disk.
Suspicion (unverified)
The server may hold an empty/unhydrated Y.Doc under the new docName after a move, which the auto-save later flushes over the file.
~/.ok/logsonly containscli command startedlines, so I couldn't confirm server-side.Workaround
Checkpoint before batch moves; after moving, check for
find . -name '*.md' -size 0and restore from git (git show <commit>^:<path>) viawrite.Related, possibly: #1094 (silently discarded writes).
🤖 Generated with Claude Code