P2 [CRF-11] Creating a token or API key for a soft-deleted user returns a 500 with a raw Postgres string, because the deleted-user guard is nested inside the optional lifetime branch and postAPIKey has no guard at all. (Knov P2, Chopper P2, Bisky P2, Leorio P2; +11 at P3)

The errors.Is(err, httpmw.ErrUserDeleted) check sits inside if createToken.Lifetime != 0, and validateAPIKeyLifetime is the only thing on this path that calls UserRBACSubject. With lifetime omitted (the default), and for POST /users/{user}/keys (no guard at all), control falls through to createAPIKey -> InsertAPIKey, where insert_apikey_fail_if_user_deleted (dump.sql:1170) raises. Verified live by several reviewers:

POST /users/{uuid}/keys/tokens (no lifetime) -> 500 "Failed to create API key." detail="insert API key: pq: Cannot create API key for deleted user"
POST /users/{uuid}/keys/tokens (lifetime set) -> 400 "Cannot create a token for a deleted user."
POST /users/{uuid}/keys                       -> 500, same pq detail

Reachable without any orphan race: ExtractUserContext resolves {user} by UUID via GetUserByID, which has no deleted = false filter. The PR description's "token create/config endpoints return 400/404 for a deleted target user" is false for two of three shapes, and the 500 leaks a driver string and burns the server-error budget.

Fix (also resolves CRF-15's status split): httpmw.UserParam(r) already returns the database.User with Deleted. Check if user.Deleted at the top of both postToken and postAPIKey, next to the existing user.IsSystem guard, and return one consistent status. Prefer httpapi.ResourceNotFound to match tokenConfig and to avoid disclosing the user's deleted state (see CRF-15). Then delete the nested ErrUserDeleted branch.

🤖

P3 [CRF-12] The comment, PR description, and test all justify the 401 by claiming the agent stops retrying; the agent retries a 401 exactly as hard as the 500 it replaced. (Knov, Razor, Kite, Hisoka, Chopper, Mafuuu, Takumi P3; Kurapika Nit)

The comment: "401 tells it to stop retrying instead of hammering a 500." But agent.runLoop (agent/agent.go:604) wraps run() in retry.New(100ms, 10s) and exits only on context cancellation or a.isClosed(); nothing in agent/ or codersdk/agentsdk/ inspects an HTTP status on the connect path. Takumi adds that the only permanent-status list (workspacesdk/dialer.go) lists both 401 and 500 as permanent, and that this middleware runs once at the websocket upgrade so an already-connected agent keeps its session regardless.

The 401 status is correct on its own terms (a deleted owner is a client condition, not a server error, and it keeps deleted-owner agents out of the 5xx rate). The stated mechanism does not exist, and workspaceagent_test.go:99 encodes the false claim ("terminal 401, not a retryable 500") while asserting only the status code. Drop the retry claim from the comment, the test comment, and the PR description, or make it true in runLoop in a separate change.

🤖

P3 [CRF-13] The chatd fail-closed branches use xerrors.New, which drops the %w sentinel chain and leaves a permanent condition unmarked terminal, so retryGenerationPhase retries it three times. (Ryosuke, Meruem, Kite, Mafuuu, Ging-go, Zoro, Pariston, Takumi, Chopper, Melody P3)

forcedMCPServerConfigsForOwner returns xerrors.New("chat owner has been deleted"), replacing xerrors.Errorf("load chat owner authorization: %w", err). Two costs. First, errors.Is(err, httpmw.ErrUserDeleted) is now false for every caller above, so the sentinel this PR introduced to make classification possible is destroyed at these sites; the pre-change wrapped error carried strictly more information. Second, the error reaches prepareGeneration under retryGenerationPhase (generation.go:462), which only short-circuits on isTerminalGeneration (errTerminalGeneration). A soft-deleted owner is permanently unauthorizable, but the turn burns generationPhaseMaxAttempts = 3 with 200ms/400ms backoff and logs misleading "retrying" warnings.

Siblings at chatd.go:1655 and chattool/listtemplates.go:445. Fix: keep the chain and mark terminal, e.g. terminalGeneration(xerrors.Errorf("chat owner has been deleted: %w", err)), or delete the branches since the wrapped fallthrough already fails closed. Note (Zoro): at listtemplates.go:445 the reworded string does reach the model via asOwner, so keep the wording there but keep the %w.

🤖

P3 [CRF-15] The model-override deleted-member guard only fires for mode=model and non-self callers, and the normal soft-delete path 500s in middleware before it; the response also uses 400 and discloses the deleted state, unlike the PR's sibling sites. (Knov, Mafuuu P3; Razor Note)

putUserChatPersonalModelOverride resolves member := httpmw.OrganizationMemberParam(r), then reaches UserRBACSubject only inside case ChatPersonalModelOverrideModeModel under if apiKey.UserID != member.UserID. Requests with mode=chat_default/deployment_default skip it. And in the normal path, delete_deleted_user_resources removes the user's organization_members rows, so ExtractOrganizationMember returns 0 rows and organizationparam.go 500s ("Expected exactly one organization member, but got 0", labeled "should never happen") before this branch runs. So the site is only reachable in the orphan state, and the guard is placed where a UserRBACSubject call happened to exist rather than where member is resolved. Check member.UserID's deleted flag once after it is resolved, and pick a status consistent with CRF-11 (404). The 400 message here also discloses the target's deleted state; userparam.go deliberately uses a constant message so no state about the queried user leaks (see CRF-11).

🤖

P3 [CRF-16] The deleted-owner 401 uses hard httpapi.Write, not optionalWrite, contradicting the CRF-1 decision one file over; on the one Optional: true mount it hard-fails instead of degrading to anonymous. (Ryosuke, Melody P3; Kurapika Note)

The middleware's own rule (workspaceagent.go:68-69) reserves optionalWrite for "token is not provided or is invalid"; the adjacent sql.ErrNoRows branch obeys it. An api-key/agent-token row whose owner is deleted is exactly that case, and apikey.go:293 deliberately omits Hard for it so public workspace apps fall through anonymous (CRF-1). Here the same condition writes hard. enterprise/coderd/coderd.go:681 mounts this middleware with Optional: true on GET /appearance.

Honest caveat: this branch is consistent with the inactive-user sibling two lines below (which also uses hard Write), so the inconsistency is with the apikey path, not within this file (Kurapika). This needs a deliberate call: either soft (match CRF-1, since a deleted owner is the same "credential belongs to a gone user" case) or hard (match the inactive sibling) and say which and why. The DeletedOwner test uses Optional: false, so the differing branch is uncovered.

🤖

P3 [CRF-22] Three byte-identical twelve-line ErrUserDeleted prologues in chatCreateWorkspace, chatStartWorkspace, and chatStopWorkspace; extract one helper. (Bisky, Zoro P3)

The three functions differ only in return type: identical comment, UserRBACSubject call, errors.Is branch, 403 body, and ctx = dbauthz.As(ctx, actor). Triplicated fail-closed branches drift independently, and the next status or message change will touch three places and miss one. Extract a chatOwnerContext(ctx, ownerID) (context.Context, error) (the shape chattool/listtemplates.go asOwner already demonstrates), then each call site is four lines, and there is one place to test. TestChatStopWorkspace_BypassesRequireActiveVersion already drives one of them and can be copied for the helper test. The fourth model-override site (5214) is a different unit; keep it separate (see CRF-15).

🤖

Nit [CRF-23] Comment hygiene across the routing sweep. (Gon, Ryosuke, Leorio, Mafu-san, Zoro)

Three things, all against AGENTS.md's "put each fact in one place" and "no review-history comments": (1) the "Chats are not purged when their owner is soft-deleted" rationale is pasted verbatim at six sites (exp_chats.go:3556/3641/3725, chatd.go:1228/1651, listtemplates.go:441); state it once on the ErrUserDeleted declaration and leave one-line pointers. (2) apikey_test.go:341 narrates this PR's review history ("pre-fix, the middleware would call the IdP..."); there is no "pre-fix" in the merged tree, so say what the fixture constructs instead. (3) several new comments restate the status code on the next line ("not a server error" above a non-5xx return); keep only the part a reader cannot see, e.g. that GetUserByID resolves soft-deleted users. Also (Leorio): the commit subjects exceed 72 chars and one joins two changes with "and"; move the mechanism to the body.

🤖

Note [CRF-24] UserRBACSubject signals "this subject may not act" through two channels, and callers are forced to handle only one. (Knov P3; Chopper, Zoro Note)

The deleted case is a forced error return; the suspended case is the UserStatus value, which 12 of 14 call sites discard (actor, _, err :=). So refreshTokenGrant correctly maps ErrUserDeleted to invalid_grant but a suspended user's refresh token still proceeds to apikey.Generate and gets a fresh session token. Not exploitable, because ExtractAPIKeyMW re-checks status downstream and the minted key is inert. It is a contract asymmetry, pre-existing but now concentrated in the shared helper this PR makes the decision point: if a deleted user may not act, neither may a suspended one, and the API lets a caller silently forget the second. Recording, not blocking.

🤖

Note [CRF-25] Reject-on-read never removes the orphaned api_keys row, so the bad state is tolerated on every request instead of eliminated. (Meruem Note)

Nothing sweeps api_keys rows whose user is deleted; dbpurge deletes only expired keys, so an orphaned row with a live expires_at is presented and rejected on every request until it expires, each rejection costing a GetAuthorizationUserRoles round trip. DeleteAPIKeysByUserID already exists. A purge pass over api_keys joined to users.deleted would make the bad state stop existing rather than being permanently tolerated, and it does not depend on #28546. Worth considering as the other half of the same fix; not blocking this PR.

🤖

Note [CRF-26] softDeleteUserKeepRows silently requires a superuser test role. (Kite, Ryosuke, Meruem, Hisoka Note)

SET LOCAL session_replication_role = replica is a superuser-only GUC (the previous ALTER TABLE ... DISABLE TRIGGER needed only table ownership). It works in CI and against the dockerized postgres here, but a developer pointing CODER_PG_CONNECTION_URL at a least-privilege role gets a raw permission denied to set parameter from require.NoError with no hint about the cause. One clause in the helper comment naming the requirement resolves it. Not a regression, just an unnamed environmental assumption.

🤖