Repository navigation
🤖 CoderMCPServer: disable the config in Coder when credential consent is withdrawn #311
Description
Problem
Once the dormant CoderMCPServer controller applies a config (#307), Coder holds the config enabled with the credentials from the referenced Secrets. Later, a Secret owner can withdraw consent: delete the Secret, remove the coder.com/credential=true label, or remove the config's origin from coder.com/credential-destinations. readMCPServerCredentials then stalls before any Coder call (fail static). The config stays enabled in Coder, and Coder keeps sending the stored credential to the MCP server for every member who can read it.
The kind is not registered, so no install is affected today.
Expected
The same rule as CoderAIProvider (#276, #290):
- For an object with
status.configID, a credential Secret that is deleted, loses the opt-in label, or stops listing an origin that Coder sends the credential to makes the controller verify the recorded config and the destination that Coder currently holds. - It then disables the config in Coder with one PATCH that holds
enabled: falseand no credential and no destination field. - A spec edit is needed to enable it again (the kill-switch rule).
- envtest coverage for each of the three cases after a successful apply.
Gate
The #155 plan lists this as gate G8, implemented in M6. It must land before the activation PR M9.
Found by the Codex normal and security reviews of #307.
Refs #155
Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high • Cost: $94.89
Activity
ThomasK33 commentedon Oct 14, 2026
#330 implements this issue (the disable, the consent check against what Coder holds, and the tests for each case). It says "Refs #311", not "Fixes", because one part of the spec-edit rule (item 3 above) is still open:
Remaining before M9 (gate G8): with a newer generation that is not applied yet, the disable PATCH can commit while its answer is lost, or the status write after it can fail.
status.appliedGenerationthen stays on the old generation. If the Secret gets consent back before the next disable reconcile records the disable, the sync applies the pending generation and enables the config without a spec edit after the disable. The re-enable happens only after the credential read passes again, so no credential goes to an origin without consent. What breaks is the rule that a spec edit is needed to enable the config again.A one-line marker in the
!found.Enabledbranch is not enough: that branch also sees a pending edit fromenabled: falsetoenabled: true. The fix needs a design choice (for example, persist the marker before the disable PATCH) and a test.Found by the Codex review of #330 (thread 4267416953). Deferred after two fix rounds on an advisor's recommendation. This issue stays open until it is fixed, so the G8 check before M9 catches it.
Generated with
xum• Model:anthropic:claude-opus-5-5• Thinking:high• Cost:$127.81🤖 fix: require https for Coder's revocation URL in the CoderMCPServer…