Low priority — noticed incidentally while running the #153 KG sweep across agent data dirs. Not investigated beyond what's below.
Observation
data/agents/target_agent/ exists and holds a complete agent scaffold:
data/agents/target_agent/.mcp.json (mtime Jul 24 10:49)
data/agents/target_agent/.claude/settings.json
data/agents/target_agent/.claude/hook_working.py
data/agents/target_agent/.claude/hook_idle.py
data/agents/target_agent/.claude/hook_tmux_{wake,pre_tool,post_tool,session_start,stop_failure}.py
data/agents/target_agent/.claude/hook_verify_effort.py
data/agents/target_agent/{data,output,workspace}/
Directory created 2026-04-09. target_agent is not a registered agent — it does not appear in list_agents (dymok, kotik, kuzya, mora, murzik, persik, pushok, ryzhik, solik, vaska) and no row matches in the registry.
target_agent is the parameter name of the cross-agent memory tools (reflect_for, kg_add_for, recall_for). The two source hits for the literal are only result-dict keys (src/pinky_memory/server.py:449,486), not path construction — so I found no live code path that would create this from a literal today.
Why it might be worth a look
The .mcp.json was regenerated 2026-07-24, four months after the directory was created, for an agent with no registry row. Per the usual behavior, .mcp.json is regenerated from the DB on restart. Two candidate explanations, and I have not distinguished them:
- Config regeneration iterates
data/agents/*/ rather than the registry. If so, any stray directory is maintained indefinitely, and a generated .mcp.json — which carries server config and can carry credentials — lands in a directory nobody owns.
- It was registered once (as a test?) and later deregistered, leaving the directory, with the Jul 24 mtime coming from some fleet-wide pass.
(2) is benign housekeeping. (1) is a small correctness/hygiene issue worth knowing about, mostly because an unowned directory receiving generated config is the kind of thing that drifts quietly.
I did not open .mcp.json (it may contain credentials) and did not delete anything — the directory is four months old and I don't know who created it or why.
Suggested
- Confirm which explanation holds; if (1), drive regeneration from the registry rather than the filesystem.
- If it's just a dead test artifact, remove the directory — after whoever created it confirms.
🤖 Filed by Barsik
Low priority — noticed incidentally while running the #153 KG sweep across agent data dirs. Not investigated beyond what's below.
Observation
data/agents/target_agent/exists and holds a complete agent scaffold:Directory created 2026-04-09.
target_agentis not a registered agent — it does not appear inlist_agents(dymok, kotik, kuzya, mora, murzik, persik, pushok, ryzhik, solik, vaska) and no row matches in the registry.target_agentis the parameter name of the cross-agent memory tools (reflect_for,kg_add_for,recall_for). The two source hits for the literal are only result-dict keys (src/pinky_memory/server.py:449,486), not path construction — so I found no live code path that would create this from a literal today.Why it might be worth a look
The
.mcp.jsonwas regenerated 2026-07-24, four months after the directory was created, for an agent with no registry row. Per the usual behavior,.mcp.jsonis regenerated from the DB on restart. Two candidate explanations, and I have not distinguished them:data/agents/*/rather than the registry. If so, any stray directory is maintained indefinitely, and a generated.mcp.json— which carries server config and can carry credentials — lands in a directory nobody owns.(2) is benign housekeeping. (1) is a small correctness/hygiene issue worth knowing about, mostly because an unowned directory receiving generated config is the kind of thing that drifts quietly.
I did not open
.mcp.json(it may contain credentials) and did not delete anything — the directory is four months old and I don't know who created it or why.Suggested
🤖 Filed by Barsik