Stdio MCP connectors store executable paths under /home/box/agent-data/agents/<agentId>/secrets/.... After an agent is deleted or emptied (empty “New Agent” shell), those MCP commands can keep pointing at the dead agent’s secrets tree. Spawn then fails with ENOENT (e.g. spawn .../agents/fca450d8-.../secrets/alpaca-mcp.sh ENOENT) because the script was a symlink into a deleted agent folder. Restarting MCP does not fix a missing file. Manual restore of a real wrapper + RestartMcpServers recovered the connectors.
Concrete case (2026-09-07, Plummer triage):
alpaca-paper / alpaca-paper-read / alpaca-judge failed with ENOENT on alpaca-mcp.sh under agent fca450d8-93af-48db-9767-acd7c0faac01
Script was a symlink to deleted agent 2a4856ef-...
Empty New Agent shell still held the broken link until a real wrapper was restored
Steps to Reproduce
Install/configure a stdio MCP whose command lives under an agent’s secrets/ directory.
Delete or empty that agent (or the secrets target) without rebinding the MCP command.
Observe MCP status error failed_to_load / spawn ENOENT for that path.
RestartMcpServers → still fails until the path is rewritten.
Expected Behavior
Deleting/emptying an agent rebinds or clears MCP commands that pointed at its secrets; status should not permanently reference dead agent-data paths.
Your MCP servers are account-wide (shared by all your bots), but each bot’s agents/<agentId>/ folder is deleted along with the bot. So a wrapper (or symlink) living inside a bot’s secrets/ disappears when you delete that bot, and the servers are left pointing at a path that’s gone. Restart can’t recreate the file, which is why restoring the wrapper fixed it.
Fix: keep wrapper scripts and creds in a bot-independent spot like /home/box/mcp-wrappers/, re-point the three Alpaca servers there (re-add or edit the command), then Restart MCP. Or skip the wrapper and register each server with its real command (npx -y <package> / uvx <package>), passing the keys via the server’s env.
Agreed it shouldn’t leave servers pointing at a deleted bot’s folder. That isn’t intended behavior and it’s an issue we’re tracking. I’ll follow up here when there’s an update.
Conversation ID / bot: the servers are account-wide, not tied to one bot. The spawn path points into agent folder fca450d8-93af-48db-9767-acd7c0faac01, the same one from my original post. Its profile is an empty “New Agent” shell with no clear owning bot.
What happened (2026-09-24, ~8:07 PM ET)
The Grok Bot computer was rebuilt/updated. All agents/<id>/ folders were recreated between 20:07:04 and 20:10:08 ET (profile.json, settings.json, store.db).
Agent folder fca450d8-… came back with onlyprofile.json, settings.json, store.db. Its secrets/ subfolder was not recreated.
Four custom stdio servers are still registered with launch scripts under that path, and all four failed: user-github-local, user-alpaca-paper, user-alpaca-paper-read, user-alpaca-judge failed_to_load: spawn /home/box/agent-data/agents/<agent-id>/secrets/<wrapper>.sh ENOENT
The bot-independent folder /home/box/agent-data/mcp-wrappers/did survive the rebuild. All the wrapper files are still there.
Earlier on 2026-09-24, routine checks had already shown user-github-local ENOENT.
The same thing happened on 2026-09-22. So this recurs on rebuilds/updates, not just once.
Why the earlier advice didn’t stick
The fix suggested above was to re-point the servers to a stable folder. But there’s no way to edit an existing custom stdio server’s command in place. The only option is uninstall + re-add, and that also drops the server’s custom MCP instructions. So the registrations kept the agents/<id>/secrets/… path, and a rebuild that doesn’t recreate secrets/ breaks them again. I filed a separate feature request for in-place editing.
Workaround (works)
Point the dead path at the stable folder with a symlink, then restart MCP: ln -s /home/box/agent-data/mcp-wrappers /home/box/agent-data/agents/<agent-id>/secrets → Restart MCP servers → all four reconnected.
The next rebuild will probably drop that symlink too, because it recreates the agent folder without it.
Expected
A computer rebuild/update should keep the files that registered stdio MCP commands point at, including agents/<id>/secrets/. Or it should migrate or re-point those registrations and flag them in the UI, instead of silently leaving servers in failed_to_load.
Impact
The GitHub (local) connector and all three Alpaca connectors were down from the rebuild until manual repair, and this happens on each rebuild (Sep 22 and Sep 24). Scheduled automations that depend on them fail silently until someone notices.
Sanitized evidence (ls -la after the rebuild; wrapper contents deliberately left out):
agents/fca450d8-93af-48db-9767-acd7c0faac01/
profile.json 104 B 2026-09-24 20:07:10 ET (name: "New Agent", empty shell)
settings.json 35 B 2026-09-24 20:07:04 ET
store.db 49152 B 2026-09-24 20:10:08 ET
secrets -> /home/box/sand-data/mcp-wrappers (symlink added by hand 22:52 ET as the workaround)
/home/box/agent-data/mcp-wrappers/ (survived the rebuild)
alpaca-mcp.sh github-mcp.sh fastmail-mcp.sh fastmail_mcp.py run-wyze-mcp.sh run-wyze-mcp.py __pycache__/
mtimes 2026-09-24 20:09:36–20:09:39 ET, mode 0700
(/home/box/agent-data is a symlink to /home/box/sand-data.)
Of the 24 agent folders after the rebuild, only one still had a real secrets/ dir. The 11 thin
empty-shell agent folders (only profile.json, settings.json, store.db; fca450d8 is one of them)
had no secrets/ at all. The manual symlink is the only exception.