🤖 CoderMCPServer: decide whether an unresolved group blocks removing old access #313

Problem

When a new generation of a CoderMCPServer names a group in spec.access.groups that does not exist in Coder, the apply step of #307 stops with GroupNotFound before it changes anything. That follows the plan's fail-static rule (#155 plan 4.8 item 3: "If a name does not resolve, the controller changes nothing and reports GroupNotFound").

A consequence: if the earlier generation allowed a broader group (for example Everyone), that group keeps access to the enabled config until the new group exists. This also holds when the same generation sets enabled: false or changes the URL, because the config PATCH is not sent either. The object reports Stalled with GroupNotFound.

The kind is not registered, so no install is affected today.

Decision needed before activation (M9)

Option A: keep fail static, as the plan says now, and document it in the how-to.

Option B: on GroupNotFound, still run the remove-only pass by name from the ACL answer (Coder returns each group's name), and send enabled: false when the new generation disables the server. Then add the groups once they resolve.

Found by the Codex normal and security reviews of #307 (threads 4266502717 and 4266511679).

Refs #155

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high • Cost: $94.89