GitHub OAuth consent screen uses personal ClawdHub app branding

[Patrick-Erichsen]

Problem

The GitHub OAuth consent screen for ClawHub sign-in currently presents the app as a personal/unofficial integration:

This is user-facing during web and CLI auth, so it undermines trust at the exact moment users are granting account access.

Evidence

Observed consent copy:

ClawdHub by Peter Steinberger wants to access your <github-login> account

Repo findings:

• convex/auth.ts configures Convex Auth with the Auth.js GitHub provider.
• The OAuth app is selected by Convex env vars AUTH_GITHUB_ID and AUTH_GITHUB_SECRET.
• auth.addHttpRoutes(http) mounts the OAuth endpoints under /api/auth/*.
• Convex Auth builds the callback URL as (CUSTOM_AUTH_SITE_URL ?? CONVEX_SITE_URL) + "/api/auth/callback/github".
• Production docs list AUTH_GITHUB_ID, AUTH_GITHUB_SECRET, CONVEX_SITE_URL, and SITE_URL as deploy envs.

Likely root cause

The production AUTH_GITHUB_ID appears to point at a GitHub OAuth App named ClawdHub owned by Peter's personal account instead of an official OpenClaw/ClawHub-owned OAuth App.

This is separate from the GitHub App backup/sync credentials (GITHUB_APP_ID, GITHUB_APP_INSTALLATION_ID, GITHUB_APP_PRIVATE_KEY). Those do not control the user login consent screen.

Expected behavior

The consent screen should show an official ClawHub-owned OAuth app, for example:

ClawHub by OpenClaw wants to access your <github-login> account

Proposed fix

1. Create or transfer the OAuth App to the official GitHub org/account.
2. Set the app name to ClawHub.
3. Set homepage URL to https://clawhub.ai.
4. Set authorization callback URL to the production Convex auth callback:
   • likely https://wry-manatee-359.convex.site/api/auth/callback/github, unless CUSTOM_AUTH_SITE_URL is intentionally set.
5. Update Convex production env:

bunx convex env set --prod AUTH_GITHUB_ID <official-client-id>
bunx convex env set --prod AUTH_GITHUB_SECRET

6. Validate in a fresh/private browser and with CLI auth.

Code/docs pointers

• convex/auth.ts - GitHub provider and AUTH_GITHUB_ID / AUTH_GITHUB_SECRET usage
• convex/http.ts - auth.addHttpRoutes(http)
• CONTRIBUTING.md - local callback URL shape
• specs/deploy.md - production auth env vars
• vercel.json - current /api/* rewrite to the Convex site

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 18, 2026, 4:12 PM ET / 20:12 UTC.

Summary
Keep open: current main and v0.22.0 still route GitHub sign-in through the OAuth app selected by Convex environment credentials, so source review does not prove the production consent-screen branding has moved to an official app. The issue is collaborator-authored and auth/security-sensitive, so it needs maintainer/operator follow-up rather than conservative cleanup.

Reproducibility: no. for the exact live production branding: the issue screenshot shows the reported consent copy, and source confirms the branding is controlled by the OAuth app selected by AUTH_GITHUB_ID, but I did not exercise a fresh production OAuth approval flow.

Ways to help us reproduce this

• Add expected vs actual behavior.

Next step
Manual review is required because this is collaborator-authored, security/auth-provider-sensitive, and the remaining action is production OAuth app ownership plus credential rotation rather than a source-only repair.

Security
Needs attention: The issue is security-sensitive because OAuth consent app identity is the user-facing trust boundary for granting GitHub account access.

Review details

Best possible solution:

Have a maintainer create or transfer the production GitHub OAuth app to the official OpenClaw/ClawHub owner, rotate AUTH_GITHUB_ID and AUTH_GITHUB_SECRET together, and verify web plus CLI sign-in against the real consent screen.

Do we have a high-confidence way to reproduce the issue?

No for the exact live production branding: the issue screenshot shows the reported consent copy, and source confirms the branding is controlled by the OAuth app selected by AUTH_GITHUB_ID, but I did not exercise a fresh production OAuth approval flow.

Is this the best way to solve the issue?

Yes: changing or transferring the production OAuth App and rotating the existing Convex production credentials is the narrowest maintainable fix. A source-only PR would not change GitHub's consent branding unless production OAuth ownership/configuration changes too.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The current production GitHub OAuth app owner/name and Convex production AUTH_GITHUB_ID cannot be proven from source alone.
• Changing OAuth app ownership, callback URLs, or secrets can break web and CLI sign-in if the official app and Convex production environment are not updated together.

Codex review notes: model internal, reasoning high; reviewed against 22d3cd133cb6.

Label changes

Label justifications:

• P2: The report affects trust during authentication but appears bounded to OAuth configuration rather than an active outage or confirmed compromise.
• impact:security: Users are asked to grant GitHub account access to an OAuth app whose visible owner and branding are the trust boundary under review.
• impact:auth-provider: The affected behavior is controlled by the GitHub OAuth provider credentials selected by Convex environment variables.

Evidence reviewed

Security concerns:

• [medium] Verify official OAuth app ownership
  The visible consent-screen identity is controlled by GitHub OAuth App ownership and Convex production credentials outside the source tree, so maintainers should verify or replace the production app before treating this as resolved.
  Confidence: 0.84

What I checked:

• Repository policy read: AGENTS.md was read fully; its guidance on security-sensitive auth flows, production operations, and maintainer review routing affected this review. (AGENTS.md:1, 22d3cd133cb6)
• Live issue state: GitHub reports this issue still open, assigned for follow-up, and labeled for security/auth-provider review; the provided context reports the author association as COLLABORATOR.
• Reported visual evidence: The attached screenshot shows the consent copy as "ClawdHub by Peter Steinberger" requesting access to a GitHub account.
• Current GitHub provider source: Current main creates the Auth.js GitHub provider from AUTH_GITHUB_ID and AUTH_GITHUB_SECRET, so the visible consent app identity is controlled by the configured OAuth app rather than repository UI copy. (convex/auth.ts:34, 22d3cd133cb6)
• Auth route source: Current main mounts Convex Auth routes with auth.addHttpRoutes(http), matching the /api/auth callback path described in the issue. (convex/http.ts:65, 22d3cd133cb6)
• Production environment documentation: Deployment docs list AUTH_GITHUB_ID, AUTH_GITHUB_SECRET, and CONVEX_SITE_URL as production environment values, supporting that the remaining fix is OAuth app ownership plus Convex production credential rotation. (specs/deploy.md:106, 22d3cd133cb6)

Likely related people:

• Patrick-Erichsen: Patrick authored the collaborator report and recent blame/log history points to commits touching the auth provider and deployment docs used by this path. (role: recent auth/deploy area contributor and reporter; confidence: high; commits: 911515194911, e3e5705d8969, 86898837fb3a; files: convex/auth.ts, convex/http.ts, specs/deploy.md)
• joshavant: Recent commits changed the same GitHub OAuth provider path to harden account linking and malformed GitHub profile id handling. (role: recent auth hardening contributor; confidence: medium; commits: b3f98b46867c, 0b6466184b72; files: convex/auth.ts, convex/auth.test.ts, specs/auth-identity.md)
• Peter Steinberger: The original ClawHub bootstrap introduced the Convex/Auth.js surface, and the issue evidence identifies the current consent-screen branding as tied to Peter's personal account. (role: historical auth/bootstrap contributor; confidence: medium; commits: 8df19780ea0a, d8dd6542ca18; files: convex/auth.ts, convex/http.ts, README.md)
• thewilloftheshadow: Live GitHub issue data shows thewilloftheshadow assigned to this open production OAuth follow-up. (role: assigned follow-up owner; confidence: medium; files: convex/auth.ts, specs/deploy.md)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.