[codex] Revoke credentials when role permissions change

[benjaminshafii]

Summary

• Revokes sessions, organization API keys, and org-scoped OAuth credentials for active members holding a custom role when that role's permission map changes.
• Wires the revocation into organization role updates without changing role creation, deletion, or permission validation behavior.
• Adds focused regression coverage for role-member credential revocation.

Why

Changing a custom role permission map can grant or remove sensitive delegated security capabilities for every current member with that role. Direct member role changes already revoke credentials; role permission-map changes now get the same treatment.

Validation

• pnpm install --frozen-lockfile passed.
• pnpm --filter @openwork-ee/den-db build passed.
• pnpm --filter @openwork-ee/utils build passed.
• pnpm --filter @openwork-ee/den-api build passed.
• pnpm --dir ee/apps/den-api exec tsc -p tsconfig.json --noEmit passed.
• bun test ee/apps/den-api/test/organization-role-credential-revocation.test.ts ee/apps/den-api/test/org-role-permissions.test.ts ee/apps/den-api/test/org-identity-access.test.ts passed, 13 pass / 0 fail.
• bun test ee/apps/den-api/test passed, 144 pass / 0 fail.
• git diff --check passed.
• git diff --cached --check passed before commit.

Daytona Evidence

• Reviewed the Daytona opencode server skill and used .devcontainer/test-server-on-daytona.sh for this server-only validation.
• Daytona sandbox openwork-security-role-revoke-20260613-202528 checked out commit c1429c3.
• Den API health passed: GET /health returned {"ok":true,"service":"den-api"}.
• Den Web proxy health passed: GET /api/den/health returned {"ok":true,"service":"den-api"}.
• Worker proxy unknown-worker smoke returned HTTP 404 with worker_not_found, as expected.
• Focused Daytona test run passed: 13 pass / 0 fail.
• Temporary Daytona sandbox was deleted after validation.

Live Smoke

Video is not relevant for this server-only authorization/credential lifecycle hardening; the focused Daytona server smoke and tests are the relevant runtime evidence.

Merge Note

Draft PR only. Do not merge until reviewed.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
openwork-app	Ready	Preview, Comment	Jun 14, 2026 3:29am
openwork-den	Ready	Preview, Comment	Jun 14, 2026 3:29am
openwork-den-worker-proxy	Ready	Preview, Comment	Jun 14, 2026 3:29am
openwork-landing	Ready	Preview, Comment, Open in v0	Jun 14, 2026 3:29am

[cubic-dev-ai]

1 issue found across 3 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="ee/apps/den-api/src/routes/org/roles.ts">

<violation number="1" location="ee/apps/den-api/src/routes/org/roles.ts:221">
P1: Credential revocation is non-atomic with the role permission update, so revocation failures can leave stale credentials after a successful permission change. This is a fail-open security gap in the new hardening path.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: Credential revocation is non-atomic with the role permission update, so revocation failures can leave stale credentials after a successful permission change. This is a fail-open security gap in the new hardening path.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At ee/apps/den-api/src/routes/org/roles.ts, line 221:

<comment>Credential revocation is non-atomic with the role permission update, so revocation failures can leave stale credentials after a successful permission change. This is a fail-open security gap in the new hardening path.</comment>

<file context>
@@ -215,6 +217,13 @@ export function registerOrgRoleRoutes<T extends { Variables: OrgRouteVariables }
     }
 
+    if (permissionChanged) {
+      await revokeCredentialsForOrganizationRoleMembers({
+        organizationId: payload.organization.id,
+        role: nextRoleName,
</file context>