ENG-3056

Docs preview

Check off each page once it's been reviewed. If a page changes in a later push, its checkbox clears automatically so it gets a fresh look. Pages not yet wired into the docs navigation aren't listed here.

• docs/admin/integrations/oauth2-provider.md
• docs/admin/security/audit-logs.md
• docs/reference/api/enterprise.md
• docs/reference/api/schemas.md
• docs/reference/cli/index.md
• docs/reference/cli/oauth2-provider.md
• docs/reference/cli/oauth2-provider_dcr.md
• docs/reference/cli/oauth2-provider_dcr_disable.md
• docs/reference/cli/oauth2-provider_dcr_enable.md

Manual verification: OAuth2 Dynamic Client Registration admin toggle

Ran the flows below against a local dev Coderd (./scripts/develop.sh) to confirm the behavior end-to-end, on top of the automated test suite. Each section shows the flow being exercised, then the actual request/response captured while testing (collapsed below each diagram).

Summary

0. Prerequisites

./scripts/develop.sh   # Terminal 1, leave running

./scripts/coder-dev.sh login   # Terminal 2
export SESSION_TOKEN=$(cat ./.coderv2/session)
export BASE_URL=http://localhost:3000
export AUTH_HEADER="Coder-Session-Token: $SESSION_TOKEN"

export ORG_ID=$(curl -s "$BASE_URL/api/v2/users/me" -H "$AUTH_HEADER" | jq -r '.organization_ids[0]')
curl -s -X POST "$BASE_URL/api/v2/users" -H "$AUTH_HEADER" \
  -H "Content-Type: application/json" \
  -d '{"email": "dcr-member@coder.com", "username": "dcr-member", "password": "SomeSecurePassword123!", "login_type": "password", "organization_ids": ["'"$ORG_ID"'"]}'

export MEMBER_SESSION_TOKEN=$(curl -s -X POST "$BASE_URL/api/v2/users/login" \
  -H "Content-Type: application/json" \
  -d '{"email": "dcr-member@coder.com", "password": "SomeSecurePassword123!"}' | jq -r '.session_token')
export MEMBER_AUTH_HEADER="Coder-Session-Token: $MEMBER_SESSION_TOKEN"

1. Default state: DCR is disabled out of the box

Verifies coderd/oauth2provider/{metadata,registration}.go's "never configured" branch and coderd/oauth2.go's oauth2ProviderSettings GET handler.

sequenceDiagram
    participant A as Owner
    participant C as Anonymous OAuth2 Client
    participant S as coderd

    A->>S: GET /api/v2/oauth2-provider/settings
    S-->>A: 200 OK - dynamic_client_registration_enabled: false
    Note over S: Never configured (sql.ErrNoRows) -> treated as disabled

    C->>S: GET /.well-known/oauth-authorization-server
    S-->>C: 200 OK - registration_endpoint absent from response

    C->>S: POST /oauth2/register
    S-->>C: 403 invalid_request,<br/>"Dynamic client registration is disabled on this deployment"

curl -s "$BASE_URL/api/v2/oauth2-provider/settings" -H "$AUTH_HEADER" | jq .

{
  "dynamic_client_registration_enabled": false
}

curl -s "$BASE_URL/.well-known/oauth-authorization-server" | jq 'has("registration_endpoint")'

false

curl -s -w "\nHTTP %{http_code}\n" -X POST "$BASE_URL/oauth2/register" \
  -H "Content-Type: application/json" \
  -d '{"client_name": "manual-test-dcr-disabled", "redirect_uris": ["http://localhost:9876/callback"]}'

{"error":"invalid_request","error_description":"Dynamic client registration is disabled on this deployment"}

HTTP 403

✅ Pass — settings default to false, discovery omits registration_endpoint, and registration is rejected with the RFC 7591-shaped error.

2. A non-owner member can't view or change the setting

Verifies the RBAC check in coderd/database/dbauthz/dbauthz.go on GetOAuth2DCREnabled/UpsertOAuth2DCREnabled — rbac.ResourceDeploymentConfig requires a role (like Owner) that has it; the default "member" role does not.

sequenceDiagram
    participant M as Member (non-owner)
    participant S as coderd

    M->>S: GET /api/v2/oauth2-provider/settings
    S-->>M: 403 Forbidden
    M->>S: PUT /api/v2/oauth2-provider/settings
    S-->>M: 403 Forbidden

curl -s -o /dev/null -w "%{http_code}\n" "$BASE_URL/api/v2/oauth2-provider/settings" -H "$MEMBER_AUTH_HEADER"

403

curl -s -o /dev/null -w "%{http_code}\n" -X PUT "$BASE_URL/api/v2/oauth2-provider/settings" \
  -H "$MEMBER_AUTH_HEADER" -H "Content-Type: application/json" \
  -d '{"dynamic_client_registration_enabled": true}'

403

✅ Pass — non-owner member correctly denied both GET and PUT.

3. Owner enables DCR live (no restart required)

Verifies putOAuth2ProviderSettings (coderd/oauth2.go) persists the change and it's readable back immediately.

sequenceDiagram
    participant A as Owner
    participant S as coderd
    participant DB as site_configs

    A->>S: PUT /api/v2/oauth2-provider/settings<br/>{dynamic_client_registration_enabled: true}
    S->>DB: UPSERT oauth2_dcr_enabled = true
    S-->>A: 200 OK
    Note over S,DB: Audited: a new audit_logs row is written

    A->>S: GET /api/v2/oauth2-provider/settings
    S-->>A: 200 OK - dynamic_client_registration_enabled: true

curl -s -X PUT "$BASE_URL/api/v2/oauth2-provider/settings" \
  -H "$AUTH_HEADER" -H "Content-Type: application/json" \
  -d '{"dynamic_client_registration_enabled": true}' | jq .

{
  "dynamic_client_registration_enabled": true
}

curl -s "$BASE_URL/api/v2/oauth2-provider/settings" -H "$AUTH_HEADER" | jq .

{
  "dynamic_client_registration_enabled": true
}

✅ Pass — write succeeded and persisted; a fresh GET in a separate request confirms it, not just an echo of the PUT body.

3a. Same thing via the CLI

Verifies coder oauth2-provider dcr enable/disable (cli/oauth2provider.go), which wraps the same PUT call as step 3.

sequenceDiagram
    participant A as Owner (CLI)
    participant S as coderd

    A->>S: coder oauth2-provider dcr disable
    S-->>A: "Dynamic client registration is now disabled."
    A->>S: coder oauth2-provider dcr enable
    S-->>A: "Dynamic client registration is now enabled."

./scripts/coder-dev.sh oauth2-provider dcr disable
curl -s "$BASE_URL/api/v2/oauth2-provider/settings" -H "$AUTH_HEADER" | jq .

Dynamic client registration is now disabled.

{
  "dynamic_client_registration_enabled": false
}

./scripts/coder-dev.sh oauth2-provider dcr enable
curl -s "$BASE_URL/api/v2/oauth2-provider/settings" -H "$AUTH_HEADER" | jq .

Dynamic client registration is now enabled.

{
  "dynamic_client_registration_enabled": true
}

✅ Pass — both CLI subcommands round-trip correctly, each verified via a fresh API GET, not just the CLI's own success message.

3b. Non-owner member gets the same 403 via the CLI

Verifies the CLI surfaces the RBAC error from step 2 rather than swallowing it. coder-dev.sh unsets CODER_SESSION_TOKEN internally, so use the --token global flag to authenticate as the member for one invocation.

./scripts/coder-dev.sh --token "$MEMBER_SESSION_TOKEN" oauth2-provider dcr enable

Encountered an error running "coder oauth2-provider dcr enable", see "coder oauth2-provider dcr enable --help" for more information
error: Trace=[unable to enable dynamic client registration: ]
Forbidden.
You don't have permission to view this content. If you believe this is a mistake, please contact your administrator or try signing in with different credentials.

✅ Pass — CLI surfaced the wrapped RBAC 403 Forbidden error rather than swallowing it.

4. Once enabled: an anonymous client discovers and registers successfully

Verifies the flip side of step 1 — registration_endpoint now appears in discovery, and POST /oauth2/register succeeds. This client is kept alive for step 5.

sequenceDiagram
    participant C as Anonymous OAuth2 Client
    participant S as coderd

    C->>S: GET /.well-known/oauth-authorization-server
    S-->>C: 200 OK - registration_endpoint now present

    C->>S: POST /oauth2/register
    S-->>C: 201 Created - client_id, client_secret, registration_access_token

curl -s "$BASE_URL/.well-known/oauth-authorization-server" | jq '.registration_endpoint'

"http://127.0.0.1:3000/oauth2/register"

DCR_REG=$(curl -s -X POST "$BASE_URL/oauth2/register" \
  -H "Content-Type: application/json" \
  -d '{"client_name": "manual-test-dcr-client", "redirect_uris": ["http://localhost:9876/callback"]}')
echo "$DCR_REG" | jq .

{
  "client_id": "a99e9f20-fcbe-4e48-b3d4-7400e2f83b2f",
  "client_secret": "coder_sFWAcdm1If_IXPH7AFVqcJ9Gxqz0AQgUYiKZ5iCe0ZQwj28s53Z",
  "client_id_issued_at": 1784523093,
  "redirect_uris": ["http://localhost:9876/callback"],
  "client_name": "manual-test-dcr-client",
  "grant_types": ["authorization_code", "refresh_token"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "client_secret_basic",
  "registration_access_token": "cDQeLvAvBJNKmC5LYZqbOBzWxUAU14XH5yNwwFZL",
  "registration_client_uri": "http://127.0.0.1:3000/oauth2/clients/a99e9f20-fcbe-4e48-b3d4-7400e2f83b2f"
}

✅ Pass — registration succeeded with client_id, client_secret, and registration_access_token all present.

5. Owner disables DCR again: new registrations rejected, this client keeps working

The core scope boundary of the whole feature: disabling DCR is forward-looking only. Verifies registration.go's gate rejects new attempts, while RFC 7592 self-management and the token endpoints (neither of which check the flag) stay unaffected for a client that already exists.

sequenceDiagram
    participant A as Owner
    participant New as New Anonymous Client
    participant Old as Existing Client (from step 4)
    participant S as coderd

    A->>S: PUT /api/v2/oauth2-provider/settings<br/>{dynamic_client_registration_enabled: false}
    S-->>A: 200 OK

    New->>S: POST /oauth2/register
    S-->>New: 403 invalid_request

    Note over Old,S: The client from step 4 was never told to stop existing
    Old->>S: GET /oauth2/clients/{client_id}
    S-->>Old: 200 OK - unaffected

    Old->>S: PKCE authorize + token exchange
    S-->>Old: 200 OK - access_token, refresh_token
    Note over Old,S: Fully functional despite DCR being disabled deployment-wide

curl -s -X PUT "$BASE_URL/api/v2/oauth2-provider/settings" \
  -H "$AUTH_HEADER" -H "Content-Type: application/json" \
  -d '{"dynamic_client_registration_enabled": false}' | jq .

{
  "dynamic_client_registration_enabled": false
}

curl -s -w "\nHTTP %{http_code}\n" -X POST "$BASE_URL/oauth2/register" \
  -H "Content-Type: application/json" \
  -d '{"client_name": "manual-test-dcr-should-fail", "redirect_uris": ["http://localhost:9876/callback"]}'

{"error":"invalid_request","error_description":"Dynamic client registration is disabled on this deployment"}

HTTP 403

curl -s -o /dev/null -w "%{http_code}\n" "$BASE_URL/oauth2/clients/$DCR_CLIENT_ID" \
  -H "Authorization: Bearer $DCR_REG_ACCESS_TOKEN"

200

# PKCE authorize + token exchange for the existing client
VERIFIER=$(openssl rand -base64 32 | tr -d "=+/" | cut -c -43)
CHALLENGE=$(echo -n "$VERIFIER" | openssl dgst -sha256 -binary | base64 | tr -d "=" | tr '+/' '-_')
AUTH_URL="$BASE_URL/oauth2/authorize?client_id=$DCR_CLIENT_ID&response_type=code&redirect_uri=http://localhost:9876/callback&state=$(openssl rand -hex 16)&code_challenge=$CHALLENGE&code_challenge_method=S256"
REDIRECT=$(curl -s -X POST "$AUTH_URL" -H "$AUTH_HEADER" -w '\n%{redirect_url}' -o /dev/null)
CODE=$(echo "$REDIRECT" | grep -oE 'code=[^&]+' | sed 's/code=//')

curl -s -X POST "$BASE_URL/oauth2/tokens" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=authorization_code" -d "code=$CODE" -d "client_id=$DCR_CLIENT_ID" \
  -d "client_secret=$DCR_CLIENT_SECRET" -d "redirect_uri=http://localhost:9876/callback" \
  -d "code_verifier=$VERIFIER" | jq .

{
  "access_token": "vAL2d2LeM6-DGh1QsXEYeYvXBzlAJFwv0",
  "token_type": "Bearer",
  "expires_in": 86399,
  "refresh_token": "coder_leYIu6gbh6_2N4XLCNb8xR6de1XOMIp3UN9Om94fRvmmTje8Y6n",
  "expiry": "2026-07-21T04:56:09.579256Z"
}

✅ Pass — new registration rejected, discovery omits the endpoint again, and the pre-existing client's self-management and full PKCE authorize/token exchange both succeed unaffected. Confirms disabling DCR blocks only new self-registration, never already-registered clients.

6. Cleanup

curl -s -X DELETE "$BASE_URL/api/v2/oauth2-provider/apps/$DCR_CLIENT_ID" -H "$AUTH_HEADER" \
  -o /dev/null -w "%{http_code}\n"

204

✅ Pass — test app deleted.

7a. Debug-log visibility for a DCR-disabled rejection

registration.go only has one explicit log call, and it's for a genuine internal failure (500), unrelated to the DCR-disabled gate. A rejected registration (403) produces no application log at all — only the generic HTTP request-logging middleware, and only at Debug level for 403s. So seeing this in server logs requires CODER_VERBOSE=true; absent that, the JSON error body returned to the client (already captured in steps 1/5 above) is the actual source of truth.

N/A — documented behavior, not a pass/fail check.

7b. Audit log records the setting change — found and fixed a real bug

Verifies the DCR setting change is durably audited with a correct before/after diff.

curl -s "$BASE_URL/api/v2/audit?q=resource_type:oauth2_provider_settings" -H "$AUTH_HEADER" \
  | jq '.audit_logs[] | {action, diff}'

{"action": "write", "diff": {"dynamic_client_registration_enabled": {"old": false, "new": true, "secret": false}}}
{"action": "write", "diff": {}}

Every enable row correctly showed old: false, new: true. Every disable row showed an empty diff, hiding that anything had changed.

Root cause: putOAuth2ProviderSettings (coderd/oauth2.go) only ever set aReq.New, never aReq.Old. audit.InitRequest zero-initializes aReq.Old to database.OAuth2ProviderSettings{} (DynamicClientRegistrationEnabled: false), so the diff compared against that zero value instead of the real prior state. Going false → true, the zero value happened to match the real prior state, so the diff came out correct by coincidence. Going true → false, the zero-value Old (false) matched the real New (false), so Diff() reported no change at all.

Fix: putOAuth2ProviderSettings now calls GetOAuth2DCREnabled(ctx) before the upsert (same never-configured/RBAC-error handling as the GET handler) and sets aReq.Old from the real previous value.

Regression coverage: TestOAuth2ProviderSettingsAuditDiff (enterprise/coderd/oauth2providersettings_audit_test.go) asserts real old/new values on both directions. This needed a real entaudit.NewAuditor, since the audit.NewMock() used elsewhere always stubs the diff to Map{} and can't catch this class of bug. Confirmed the test fails against the pre-fix code and passes against the fix.

curl -s "$BASE_URL/api/v2/audit?q=resource_type:oauth2_provider_settings" -H "$AUTH_HEADER" \
  | jq '.audit_logs[] | {action, diff}'

{"action": "write", "diff": {"dynamic_client_registration_enabled": {"old": true, "new": false, "secret": false}}}
{"action": "write", "diff": {"dynamic_client_registration_enabled": {"old": false, "new": true, "secret": false}}}

✅ Pass — both directions now show correct old/new values, re-verified live against a running dev server on top of the automated test.

7c. coder support bundle is not useful for DCR troubleshooting

Ruled out explicitly since it's the obvious first thing to reach for. Checked support/support.go directly: there is no reference to OAuth2ProviderSettings, oauth2, register, or dcr anywhere in what a support bundle collects. It captures no DCR registration failures and does not show whether the flag is enabled (Deployment.Config is static serpent flags, not the site_configs-backed runtime setting). Use GET /api/v2/oauth2-provider/settings directly, and 7a's debug logging, instead.

N/A — scoping note, ruled out.

8. Testing the upgrade path: existing deployment → this branch

Everything above exercises a deployment created fresh with this branch's schema already in place. This verifies migrations 000546-000549 apply cleanly against a deployment that already existed before this feature, with real pre-existing data.

sequenceDiagram
    participant Old as coderd (origin/main, pre-DCR-flag)
    participant PG as .coderv2/postgres (same data dir both runs)
    participant New as coderd (this branch)

    Old->>PG: migrate up through 000545
    Old->>PG: create admin user, OAuth2 app, etc.
    Note over Old: stop (Ctrl+C)

    New->>PG: migrate up (000546, 000547, 000548, 000549)
    Note over PG: ALTER TYPE resource_type<br/>ADD VALUE 'oauth2_provider_settings'
    New->>PG: existing users/apps still readable
    New->>PG: GET/PUT oauth2-provider/settings works

# Baseline: checkout origin/main, fresh db, create pre-existing data.
git checkout -B upgrade-test-baseline origin/main
./scripts/develop.sh --db-reset
# ...first-user setup...
curl -s -X POST "$BASE_URL/api/v2/oauth2-provider/apps" -H "$AUTH_HEADER" \
  -H "Content-Type: application/json" \
  -d '{"name": "pre-upgrade-app", "callback_url": "http://localhost:9876/callback"}' | jq '{id, name}'

{
  "id": "6fb24f19-710a-4ab9-80eb-1302791693f0",
  "name": "pre-upgrade-app"
}

# Switch to this branch, same on-disk Postgres data, let it migrate forward.
git checkout coder-eng-3056-dcr-flag
./scripts/develop.sh

Started HTTP listener at http://0.0.0.0:3000
server is ready to accept connections
authenticated as admin user  email=admin@coder.com

# Confirm the migration landed.
PGPASSWORD=$(cat .coderv2/postgres/password) psql -h localhost -p $(cat .coderv2/postgres/port) -U coder -d coder \
  -c "SELECT version, dirty FROM schema_migrations;" \
  -c "\dT+ resource_type"

 version | dirty 
---------+-------
     549 |     f

# Confirm pre-existing data survived.
curl -s "$BASE_URL/api/v2/oauth2-provider/apps" -H "$AUTH_HEADER" | jq '.[] | {id, name}'

{
  "id": "6fb24f19-710a-4ab9-80eb-1302791693f0",
  "name": "pre-upgrade-app"
}

# Confirm the new feature works against the upgraded database.
curl -s "$BASE_URL/api/v2/oauth2-provider/settings" -H "$AUTH_HEADER" | jq .
./scripts/coder-dev.sh oauth2-provider dcr enable
curl -s "$BASE_URL/api/v2/oauth2-provider/settings" -H "$AUTH_HEADER" | jq .

{"dynamic_client_registration_enabled": false}

{"dynamic_client_registration_enabled": true}

✅ Pass — the migration applies cleanly against a database that predates this feature, pre-existing data survives untouched, and both the read and write paths work correctly against the upgraded (not freshly-created) deployment.

000549's down migration is a no-op (Postgres can't drop enum values), so this migration is one-directional — matches the same constraint already present on the sibling public-client PR's migration.

Automated equivalents

Every case above also has an automated test that's passing:

make test RUN='TestOAuth2ProviderSettings|TestOAuth2DynamicClientRegistrationDisabled|TestCreateDynamicClientRegistration_DCREnabled|TestGetAuthorizationServerMetadata_DCREnabled|TestOAuth2ProviderDCR|TestOAuth2ProviderSettingsAuditDiff|TestMigration000549AuditOAuth2ProviderSettingsEnumInSingleTxn'

Documentation Check

This PR adds an admin-controlled toggle for OAuth2 Dynamic Client Registration (DCR): DCR is now disabled by default, and owners enable/disable it live via coder oauth2-provider dcr enable|disable or GET/PUT /api/v2/oauth2-provider/settings. The auto-generated CLI/API reference (docs/reference/cli/oauth2-provider*.md, docs/reference/api/*.md, docs/reference/api/schemas.md), the audit-log resource table (docs/admin/security/audit-logs.md), and docs/manifest.json are already updated in this PR.

Updates Needed

• docs/admin/integrations/oauth2-provider.md - Addressed in 43bfeecd. A new "Dynamic Client Registration" section documents the default-disabled behavior, the CLI (coder oauth2-provider dcr enable|disable) and API (GET/PUT /api/v2/oauth2-provider/settings) controls, and the scope note that disabling blocks only new self-registrations while already-registered clients keep working.

Automated review via Coder Agents

For future PRs of this shape, consider stacking instead of one 54-file PR:

1. DB + audit plumbing — queries, dbauthz, audit wiring, migration, all generated files. Bulk of the LoC, zero behavior change.
2. Settings API + SDK — handlers, routes, codersdk, tests. Setting writable, nothing reads it yet.
3. The gate — registration/metadata checks, permission grant, tests, EnableDCR ripple. The only behavior change, so release/breaking attaches to a small diff.
4. CLI.

Your "suggested review order" section is already this list — stacked, it becomes merge structure instead of reading instructions.

_{Coder Agents on behalf of @Emyrk.}

Filed follow-up issues for exposing the new setting beyond the API/CLI, both assigned to @BobbyHo:

• UI toggle in deployment settings: Add OAuth2 dynamic client registration toggle to the deployment settings UI #27432
• Terraform provider support: Support OAuth2 dynamic client registration setting (dynamic_client_registration_enabled) terraform-provider-coderd#395

_{Coder Agents on behalf of @Emyrk.}

Reviewing from the downstream side — I'm building the terraform-provider-coderd resource that wraps this endpoint (ENG-3083 / terraform-provider-coderd#395), so I've spent a while with the SDK contract. Two observations. Neither blocks this PR, and the first is considerably more important than the second.

1. The PUT is a whole-object replace, and IAT arrives later

I gather initial_access_token_required is destined for this same struct, but in a subsequent PR. That timing is what creates the hazard — if both fields shipped together, every client would have been compiled against a two-field struct from day one. Because the second arrives later, there will necessarily be a window where clients built against today's one-field struct talk to servers that have two.

Today codersdk/oauth2.go has:

type OAuth2ProviderSettings struct {
    DynamicClientRegistrationEnabled bool `json:"dynamic_client_registration_enabled"`
}

and coderd/oauth2.go decodes it unconditionally:

var req codersdk.OAuth2ProviderSettings
if !httpapi.Read(ctx, rw, r, &req) { return }
...
tx.UpsertOAuth2DCREnabled(ctx, req.DynamicClientRegistrationEnabled)

Once IAT exists as a second plain bool, an admin who has IAT required loses it the next time an older client toggles DCR:

1. The old client marshals its one-field struct: {"dynamic_client_registration_enabled": true}.
2. The server decodes into the two-field struct; initial_access_token_required is absent.
3. Absent JSON boolean → Go zero value → false.
4. The handler upserts both fields. The IAT requirement is silently switched off.

No race, no concurrency — one user, one request. And Terraform users pin their provider version independently of their Coder version, so client/server skew is the routine state of affairs rather than an edge case.

The fix is pointer fields, so absent means "leave alone" rather than "set false", with the handler upserting only what was actually sent:

DynamicClientRegistrationEnabled *bool `json:"dynamic_client_registration_enabled,omitempty"`

To be clear, this does not have to happen in this PR. Switching bool → *bool + omitempty later is wire-compatible: old clients always emit the key, so their behaviour is unchanged, and only omitting gains new meaning. The genuine risk is simply that it gets forgotten and IAT ships as a plain bool, at which point the wipe goes live. So either make the field a pointer now while everyone has the context loaded, or drop a blocking note on the IAT ticket — both work.

One thing worth ruling out: an ETag/If-Match scheme would not help here. An old client would GET, silently discard the field it can't represent, and PUT back with a perfectly valid precondition — wiping IAT anyway. Optimistic concurrency protects against concurrent modification; this is a client that cannot represent a field. Only partial-update semantics fix it.

2. Follow-up on the audit old value

Re: #3623454406 — the InTx in 324a8f39f9 definitely helped, but I don't think it gets all the way to exact, and it seemed worth saying so rather than leaving the thread implying it does.

GetOAuth2DCREnabled is a plain SELECT with no FOR UPDATE (coderd/database/queries/siteconfig.sql), and the handler passes only TxIdentifier, so Isolation is zero → "the driver or database's default level" (coderd/database/db.go:80-82) → READ COMMITTED, which permits the lost-update anomaly. InTx's automatic retry also only engages at SERIALIZABLE (db.go:161), so there's no retry here.

The consequence is that wrapping the two statements in a transaction doesn't make the read exclusive. A plain SELECT takes no lock and blocks nobody, so two concurrent PUTs can both read the pre-state. Starting from false, with A setting true and B setting false:

The setting ends up correct — B committed last, B's value won. The audit log is what suffers:

admin-a   oauth2_provider_settings   false → true
admin-b   oauth2_provider_settings   false → false     ← reads as a no-op

B's entry claims old = false, but the row held true when B's write landed, so the chain doesn't join up and B's change looks like it did nothing — when B is in fact the admin who disabled DCR. The row lock is taken at the write, not the read, so blocking makes B's write correct while leaving its audit metadata stale.

To be fair to the fix: the InTx shrank the window from "the whole handler, potentially across two pooled connections" to "two back-to-back statements on one connection". That moved this from reliably wrong under modest concurrency to wrong only under a true microsecond-scale race, which is a real improvement.

If exactness matters, the options are roughly:

• SELECT ... FOR UPDATE — B's read then blocks until A commits. Caveat: on a never-configured deployment the row doesn't exist yet and FOR UPDATE locks nothing on a missing row, so the first concurrent writes could still race.
• Capture the old value inside the upsert via a CTE, dropping the separate SELECT. Cleanest for this shape, though a CTE's branches share a statement snapshot, so it deserves a test rather than being assumed correct.
• Isolation: sql.LevelSerializable — heavier, but InTx already has retry wired for that level.

Genuinely low severity, and the original "OK as-is for an owner-only boolean toggle" still stands. Flagging it only because the thread aimed at exact. I have not reproduced this — it's from reading the code plus documented READ COMMITTED semantics, and confirming it properly needs a real Postgres and two concurrent requests, i.e. a test on your side rather than mine.