GeezerVison

Chat automations send a saved prompt to a chat from a webhook or a schedule (RFC: Automations for Coder Agents). This PR adds the routes that read and delete them, behind the chat-automations experiment, so that create, the scheduler and the webhook endpoint can follow in small PRs. Part of CODAGT-1135.

Stacked on #32067 and #32063 through the base branch tk/automations-base-api-read, which holds both. Review only this diff. This PR is retargeted to main when both are merged.

What changed

• Three routes under /api/experimental/organizations/{organization}/chats/automations: list (with ?owner=me, a user ID or a username), get, and delete. A middleware answers 404 when the experiment is off for the caller, and when the experiment rules cannot be read.
• Access follows the RFC role table. A member with agents-access reads and deletes their own automations. Organization administrators and deployment owners read and delete every automation in the organization. The list filters rows in SQL. A caller who can read an automation but not delete it gets 403 on delete. A caller who cannot read it, or who uses the wrong organization in the path, gets 404. An API key with an external scope gets 404 on get and delete, and on list either 200 [] or, when it cannot read the organization, 404.
• codersdk.ChatAutomation is the response type, built by explicit converters. It has no secret field, only webhook_secret_version, and get and list never copy the stored secret. A chat title appears only when the caller can read that chat. An owner appears only when the caller can read that user, and a ?owner= username that names a user the caller cannot read gives 200 []. next_run_times holds up to five upcoming runs of an enabled schedule.
• chatautomation.Delete takes the automation's advisory lock, re-reads the row as the caller, and deletes it in one transaction. It is the one function that the later API and agent tool paths call.
• ChatAutomation is audited for delete. prompt and webhook_secret are masked secret fields. ResourceTypeChatAutomation loses its "retained for audit logs" comment, which is no longer true, so gofmt re-aligns the constant block.
• Two queries that the routes need: GetChatsByIDs (chat titles for a page of rows) and GetChatIDsWithQueuedMessagesByAutomationID (the delete check), both with dbauthz checks.

Suggested reading order: coderd/chatautomations.go, coderd/x/chatd/chatautomation/delete.go, coderd/database/db2sdk/chatautomation.go, codersdk/chatautomations.go, then the tests. The rest is generated code and docs.

Scope

• Not in this PR: create, update, secret rotation, the run path, the webhook endpoint, the scheduler and the agent tool. No code writes chat_queued_messages.automation_id yet.
• With the experiment off, which is the default, the routes answer 404 and nothing else changes. The experiment that chore!: remove the chat automations experiment #30412 removed was never in a tagged release, so a leftover --experiments=chat-automations flag exists only on dev or dogfood deployments, and those turn these routes on.
• Two replicas on different versions during an upgrade: no case exists. A replica without this PR has none of the routes and answers 404, as the gate does. A replica ignores a stored rule for an experiment that it does not know.

Tradeoffs

• Delete refuses while a queued message names the automation. Nothing writes such a message before the publish PR, which replaces the refusal with the queue cleanup. The refusal is a generic 500 with an empty detail and the cause in a log field, and nothing is deleted.
• The list has no pagination, as in the RFC. An organization administrator's list holds every automation of the organization (members times the per-owner cap that the create PR adds), and each row carries its prompt, up to MaxPromptBytes.
• The response has three fields beyond the RFC example: new_chat_model_config_id, project_id and reasoning_effort, named as in the create request. The RFC says PATCH "takes the same fields as create", so an editor must be able to read them. paused_reasons is always [] until the run path exists, and there is no field for the count of skipped and refused runs: that field arrives with its writer.
• The audit action map for ChatAutomation lists only delete. The generated audit log page lists every action in the map, and nothing emits create or write yet. Later PRs add the actions they emit.
• The RFC says "Custom roles can grant any chat_automation action." The custom role API lets an actor grant only the permissions that the actor holds (customRoleEscalationCheck), and no built-in role holds create. This PR adds no create route and keeps the role table: a custom role with read and delete deletes, one with read only gets 403, and one with delete and without read gets 404 and deletes nothing, because the delete re-reads the row with read.

Live check

On a local enterprise build with its own PostgreSQL, two users, and the experiment on for one of them: list, get, delete, a repeat delete (404) and a delete refused by a queued message (500, nothing deleted) behaved as described, the user with the experiment off got 404 on all three routes, the delete wrote one audit entry with the prompt masked, and a canary secret and prompt appeared 0 times in the audit log, the server log and the PostgreSQL log (the secret also 0 times in every response).

Generated with xum • Model: anthropic:claude-sonnet-5-5 • Thinking: xhigh