God agent's outbound hive messages silently stop delivering (survives restarts); agent budget UI shows bogus 100%/mirrored values

[Sharpswap]

Summary

In a long-running session (v0.5.2, packaged Windows build), the god agent's outbound hive messages (outbox/ -> other agents' inbox/) stopped being delivered. The fault is one-directional and silent: no error anywhere, files just sit in outbox/ unmoved, and log.jsonl shows zero new delivery events for "from":"god" messages while "from":"<other-agent>","to":"god" messages kept delivering the entire time.

Timeline (single session, 2026-09-13)

• Last confirmed successful god-outbound delivery: 06:55:01Z.
• After that, every subsequent god->agent message (3 different messages, re-sent multiple times with fresh filenames/content) sat undelivered for 40+ minutes.
• Two full app restarts (via Task Manager / relaunch) temporarily restored delivery for ~5-10 minutes each time, then it silently stopped again.
• A later restart did NOT restore it at all -- confirmed by testing with a brand-new message and waiting 20s+ with no delivery.
• An unprompted app-start event also fired on its own later in the session (not user-initiated) -- agents were auto archived/respawned, and delivery was still broken afterward.

Related: budget/limit UI shows incorrect values

While investigating, the "Command Center" agent panel showed the god agent's "Read budget" at 13M / 13M = 100% (red). Per-agent limit was found to be set to 0. Setting the limit field to an enormous number (2.4e42) did not change the display -- it continued showing a mirrored used/used = 100% value (now 17M/17M) rather than reflecting the new limit. Using the agent-specific "restart & continue" button did reset the display to 0%, but did not restore outbound message delivery, suggesting the budget display bug and the delivery bug may be separate issues, or the delivery gate isn't reading the same value the UI reads.

Impact

God (orchestrator) could no longer dispatch tickets, approve/merge action records, or route work to other agents via the hive. Real work was blocked until the operator manually executed the pending GitHub actions (PR merges) directly via gh outside the hive protocol, bypassing the intended Repo-Ops-agent flow entirely.

Environment

• Munder Difflin v0.5.2 (packaged), Electron 32.3.3, Windows 11 Pro 10.0.26200
• 4-agent office: 1 Claude-based god + Codex-based coder + Antigravity-based reviewer + Codex-based ops agent
• No errors/bounces logged anywhere locally (checked hive/log.jsonl and hive/cost-ledger.jsonl)

What would help

• Any server-side/relay logging that could show why god's outbound queue specifically stopped draining while inbound kept working.
• Confirmation of whether the "Read budget" hitting 100% (even from a misconfigured 0 limit) is supposed to gate outbound delivery, and whether that gate has a bug where clearing/raising the limit doesn't propagate to whatever process drains outbox/.

Happy to provide the raw log.jsonl excerpt from the affected window if useful (redacted of repo/agent specifics).

[Sharpswap]

Correction: this was a self-inflicted error on my end, not a Munder Difflin defect.

I ran a read-only diagnostic against the actual hive directory and found I had been writing every outbound message to hive/outbox/ (the hive root) instead of my own per-agent path, hive/agents/<my-agent-id>/outbox/ -- which is what the router actually scans (matching every other agent's own agents/<id>/outbox/ folder, per the app's own protocol doc). My outbox was empty the entire time; there was never a stuck queue on the app's side, because I never placed messages where the router looks.

Confirmed the fix: writing a test message to the correct per-agent outbox path delivered in under a second.

The budget-limit display anomaly I described may still be worth a look (mirrored used/used regardless of input), but it was never connected to this delivery issue -- that was purely my own path mistake. Apologies for the noise, and thanks for the platform.

[Sharpswap]

Closing -- confirmed not a platform bug, see comment above.