New hackathon users cannot complete account provisioning: brokered auth redirects to login-only dashboard with no signup path

[DannyBaanks]

Summary

The hackathon onboarding says that after installing CALL-E and signing in,
a new user will automatically receive a CALL-E account with 20 free calls.

However, as a new user on Windows, the current brokered CLI auth flow
redirects to the CALL-E dashboard login page, which exposes only
Account / Password fields and no visible signup or account-creation path.

This leaves a new participant unable to complete the documented onboarding flow.

Environment

• Windows 11
• Node v22.23.1
• npm/npx 10.9.8
• @call-e/cli 0.5.0

Reproduction

1. Run:

   npx -y @call-e/cli@0.5.0 auth login --force-login --start-only --no-browser-open

2. CLI successfully creates a fresh pending broker session:

   {
     "pending_created": true,
     "pending_status": "PENDING",
     "login_url": "https://seleven-mcp-sg.airudder.com/openagent-auth/sessions/.../start"
   }

3. Open the returned login_url.

4. The broker redirects to:

   dashboard.heycall-e.com/login?mcp_return_to=...

5. The dashboard shows only:

   • Account
   • Password
   • Login

   There is no visible signup, OAuth provider, or account provisioning link.

6. auth status remains:

   {
     "cache_exists": false,
     "pending_exists": true,
     "usable": false,
     "pending_status": "PENDING"
   }

Expected

A new hackathon participant should be able to create/provision a CALL-E
account from this flow, as described in the hackathon onboarding
("You'll get a CALL-E account with 20 free calls automatically").

Actual

The brokered auth flow reaches a login form requiring credentials that a new
participant has never been given and has no visible way to create.

Impact

This blocks the primary documented entry point for the entire CALL-E hackathon
("Install CALL-E and sign in (5 min)"). A participant following the official
installation guide hits this dead end within the first five minutes.

Suggested fix

• Add a visible signup / account-provisioning action to the dashboard login page, or
• provide the correct new-user OAuth flow directly from brokered auth, and
• document the relationship between CLI authorization, dashboard account creation,
  and hackathon call credits.

The visual product UX is excellent; this appears to be an onboarding/authentication
connection issue rather than a broader UI problem.

[DannyBaanks]

Convergent evidence: three independent entry surfaces, same dead end

Follow-up observation to the original report: the dead end is not specific to
the CLI brokered login. Three advertised new-user entry paths all converge on
the same credential-only dashboard form.

Entry surface	Flow observed	Result
Hackathon docs → CLI brokered login	calle auth login --start-only → broker session created (pending_created: true) → login_url redirects to dashboard.heycall-e.com/login?...	credential-only login form; no signup path
ChatGPT complement install	CALL-E listing → Install → MCP auth handoff with valid mcp_return_to → dashboard login	credential-only login form; no signup path
heycall-e.com direct login	Login CTA → dashboard login	credential-only login form; no signup path

Notably, the second path shows the integration plumbing itself is healthy:
complement discovery, install CTA, MCP auth handoff, and return-url
propagation (mcp_return_to=.../mcp-auth/authorize?...) all work correctly.
The handoff is built — the first-time-user counterpart (signup/provisioning)
is the missing piece.

This suggests classification as a new-user account-provisioning seam rather
than a UI bug in any single surface: every advertised entry point terminates at
a form that requires credentials a new participant has no way to create.

[Ray-56]

Priority: P1 — production onboarding blocker. There is no current evidence of credential or token compromise, but this prevents net-new users from obtaining any credentials and completing the advertised onboarding flow.

I verified that the public homepage still says that new users receive 20 free calls and sends the START CALLING CTA to the dashboard. The repository also advertises signup/free calls and directs users through calle auth login. Combined with the three independent reproductions above, the evidence points to a missing first-time-user provisioning path at the dashboard/auth boundary; the broker session and return URL propagation appear to be working.

Recommended remediation:

1. Add a visible account-creation/provisioning route to the dashboard login page and make it available from brokered CLI and ChatGPT auth flows.
2. Preserve the original broker session across signup, then return to that exact session and complete the CLI token exchange. Bind the flow with server-side state/nonce checks, strictly allowlist return targets, and reject invalid mcp_return_to values to avoid introducing an open-redirect or session-confusion issue.
3. Provision the promised starter entitlement atomically (or show an explicit recoverable failure) before reporting authentication as complete.
4. Add anonymous-user E2E coverage for CLI, ChatGPT, and direct-web entry points. Validate the full redirect chain, successful token issuance, entitlement presence, rejection of tampered return targets, and absence of credentials/tokens in URLs or logs. Include the reported Windows flow.
5. Until the product fix is deployed, update the login page and hackathon/install guidance with a real supported signup or invite/contact fallback so users are not sent to a credential-only dead end.

This appears to require a dashboard/auth-service fix rather than a CLI package release. If packaged README or skill guidance is changed as the interim mitigation, run the repository release-decision checklist and add patch changesets for the affected published packages as needed.

[Ray-56]

P1 status update: the primary onboarding blocker now appears mitigated, but it needs an anonymous-user regression check before being considered resolved.

The currently deployed dashboard login bundle now renders Continue with Google, passes the MCP/broker return parameters into the OAuth request, and shows a post-login workspace-provisioning state. Issue #105 also reports testing after the provisioning fix. This is a meaningful change from the credential-only page documented in the original report.

Please validate the production flow from a fresh browser profile and an identity that has never used CALL-E:

1. Start from CLI brokered login, ChatGPT/MCP installation, and direct web entry.
2. Complete Google sign-in and verify that exactly one account/workspace is provisioned.
3. Confirm the promised 20-call entitlement is present before onboarding reports success.
4. Confirm the browser returns to the exact originating broker session and calle auth login exchanges a usable token.
5. Tamper with the return target/state and verify the request is rejected; confirm that authorization codes and tokens do not appear in URLs, logs, or user-visible errors.

If those checks pass, update the canonical installation documentation with the real Google first-time-user path and keep only a troubleshooting pointer to this Issue. PR #104's current statement that the login page has no signup path is now stale and should not be merged as written.

[DannyBaanks]

Regression checklist status: NOT_TESTED from my side — the anonymous-user E2E requires a fresh Google identity + real browser interaction that I can't automate (Cloudflare challenge on headless fetch). I've prepared an exact step-by-step regression script so a human can execute it quickly: https://github.com/DannyBaanks/CALL-E-AUTH-RESCUE-HACKATHON/blob/main/ANONYMOUS_E2E_REGRESSION.md

Also, #105 privacy action is complete:

• body redacted to +52••••••9116
• local evidence files redacted
• repo history rewritten + force-pushed (dangling commits made unreachable, repo flipped to private while dangling-safe)
• call_id values redacted from local evidence
  Claim stays: ONBOARDING_BLOCKER = MITIGATED_PER_MAINTAINER, not VERIFIED_BY_REPORTER. PR docs: clarify account provisioning requirement for first-time CLI auth #104 text updated to match the deployed flow.

[JJasonSun]

Resolved: Google sign-in has been restored on the production dashboard. Continue with Google now provides registration for new users and login for existing users, while preserving the broker/MCP return parameters. Closing as completed.