fix(headless): resume session history in -p; better MCP files_changed - #406
Merged
Conversation
Two bugs found testing the dirge MCP delegation loop:
1. dirge -p --session <id> persisted the session but never RESUMED it —
run_print passed Vec::new() as history regardless of --session, so the
model ran cold every call. A follow-up delegation ('fix the thing you
just did') had no memory of the prior turn. The print path now threads
convert_history(&session) into run_print; --loop still passes empty.
2. The MCP server's files_changed used a git-status porcelain-LINE diff,
which misses content edits to a file that was already dirty before the
delegation (common across delegations in one session: created in #1,
edited in #2). Switch to a (size, mtime) signature per dirty path so
further edits are attributed, without falsely claiming the caller's
pre-existing untouched changes.
Resume verified live through the MCP server (a second delegate now knows
the file the first created). The files_changed change is in the long-lived
server process, so it needs a Claude Code restart to take effect live;
covered by unit tests.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two bugs found while testing the
dirge mcpdelegation loop end-to-end.1.
dirge -p --session <id>didn't resume historyThe headless print path persisted the session (so
message_countgrew) but never resumed it:run_printpassedVec::new()as the model history regardless of--session, so every headless run started cold. Through the MCP server this meant a follow-updelegate("fix the thing you just did") had no memory of the prior turn — it replied "I haven't created any file in this session."Fix: the print path now threads
convert_history(&session)(the resolved session's prior turns) intorun_print. The--loopcaller still passesVec::new()(it drives its own prompt sequence). This is a general headless bug, not MCP-specific.Verified live through the MCP server: in a fresh session, delegate #1 creates a file, delegate #2 ("append a line to the file you just created") now correctly finds and edits it.
2. MCP
files_changedmissed edits to already-dirty filesThe server computed
files_changedas agit status --porcelainline diff, which can't see a content edit to a file that was already dirty before the delegation — exactly the multi-delegation case (file created untracked in #1, edited in #2:?? pathis identical before and after). Switched to a(size, mtime)signature per dirty path, so further edits are attributed while the caller's pre-existing untouched changes aren't.Unit-tested. Note: this runs in the long-lived
dirge mcpserver process, so it needs a Claude Code restart (respawns the server with the new binary) to take effect live.Tests
4
mcp_serverunit tests (signature diff + porcelain path/rename parsing),run_printtests, full suite 2612 pass.