rulesyncとagmsgの配信設定はどこで管理するかWhen using agmsg and rulesync together, running rulesync generate can silently…

Developers who use two configuration utilities for AI coding agents together—agmsg and rulesync—can run into a subtle and easily misdiagnosed problem: running rulesync generate can silently switch off the inter-agent delivery that agmsg had previously configured. Because no error is shown when this happens, the failure is easy to overlook, which makes understanding how the two tools interact worthwhile for anyone running both in the same repository.

The symptom is simple to describe. You set up delivery between agents with agmsg, automatic reception works as expected, and then at some later point you run rulesync generate. From that moment, the automatic receiving stops. On the surface nothing looks misconfigured, and because the generate command and the loss of delivery may be separated in time, the causal link between them is easy to miss.

The underlying cause is that agmsg and rulesync manage the same files. agmsg writes its delivery configuration directly into the settings directory of each tool. rulesync, for its part, manages the files that correspond to its configured targets and features. When delete: true is set, rulesync deletes any file that has no originating source in its own configuration—that is, files it did not generate. The delivery settings that agmsg wrote independently have no such source from rulesync's point of view, so they are treated as orphans and removed.

Some background helps explain why the collision arises. rulesync addresses a genuine fragmentation problem: modern AI coding assistants and editors, including Cursor, each read their rules and instructions from their own directories and formats. rulesync lets a developer keep one canonical source and generate the tool-specific files from it, so multiple assistants stay consistent. The delete: true option is part of that design; to keep the generated output authoritative, rulesync can prune files that the source does not account for, preventing stale or leftover configuration from accumulating.

agmsg operates on a different model. It writes directly into the individual tools' configuration directories rather than routing through rulesync's source. From rulesync's perspective, those files are unmanaged, and the same cleanup behavior that keeps configuration tidy is exactly what erases agmsg's delivery settings.

Resolving the conflict therefore comes down to making sure the two tools do not fight over the same files. In broad terms, that can mean bringing agmsg's delivery settings under rulesync's source so they are regenerated rather than deleted, scoping rulesync's targets and features so they do not cover the paths agmsg writes to, or reconsidering whether delete: true should be enabled given that agmsg is also writing to those locations. The right choice appears to depend on how each project has arranged its configuration and which files each tool is expected to own.

The broader lesson is a common one in configuration management: when two tools both claim authority over the same files, one can undo the other's work without