Browser redirects to sign-in page during CAPTCHA solving, preventing music generation

[0xluk]

Description

When calling the /api/custom_generate endpoint, the Playwright browser automation gets stuck on the Suno sign-in page instead of loading the create page, causing the CAPTCHA solving process to fail with a timeout error.

Environment

• OS: macOS Silicon
• Node version: v24.12.0
• Deployment: Local development
• Cookie status: Valid (confirmed by successful /api/get_limit calls)

Steps to Reproduce

1. Set valid SUNO_COOKIE in .env file
2. Verify cookie works by calling /api/get_limit (succeeds)
3. Call /api/custom_generate endpoint with valid parameters
4. Browser launches but redirects to https://accounts.suno.com/sign-in?redirect_url=https%3A%2F%2Fsuno.com%2Fcreate

Expected Behavior

Browser should navigate to https://suno.com/create and remain on that page, allowing the CAPTCHA solving flow to proceed.

Actual Behavior

Browser redirects to the sign-in page, preventing access to the create page. The textarea lookup fails because it's on the wrong page:

• Found 0 textareas on page
• Eventually times out trying to focus on textarea

Logs

{"level":30,"msg":"Navigating to suno.com/create..."}
{"level":30,"msg":"Waiting for page to fully load..."}
{"level":30,"msg":"API response timeout - page might not be fully loaded, continuing anyway"}
{"level":30,"msg":"Triggering the CAPTCHA"}
{"level":30,"msg":"Attempting to close popup with getByLabel..."}
{"level":30,"msg":"getByLabel failed, trying alternative selectors..."}
{"level":30,"msg":"No popup found or unable to close - continuing anyway"}
{"level":30,"msg":"Looking for song description textarea..."}
{"level":30,"msg":"Hip-hop placeholder not found, trying alternative selectors..."}
{"level":30,"msg":"Found 0 textareas on page"}
{"level":30,"msg":"Filling textarea with test prompt..."}
Error generating custom audio: Timeout 30000ms exceeded.

Root Cause Analysis

The issue appears to be related to browser cookie authentication:

1. The SUNO_COOKIE works for API calls (REST endpoints)
2. However, when Playwright launches a new browser context, the cookies may not be properly recognized by Suno's frontend
3. This causes Suno to redirect to the sign-in page instead of allowing access to /create

Potential Issues

1. Cookie format mismatch: Browser cookies may need different attributes (secure, httpOnly, etc.)
2. Session token expiration: The __session cookie might be stale when the browser launches
3. Cookie domain mismatch: Cookies set for .suno.com may not work with accounts.suno.com redirect
4. Missing cookies: Some required authentication cookies might not be included in the browser context

Relevant Code

The browser launch and cookie setup happens in src/lib/SunoApi.ts:

// Line ~620-640: launchBrowser() method
const cookies = [];
const lax: 'Lax' | 'Strict' | 'None' = 'Lax';
cookies.push({
  name: '__session',
  value: `${this.currentToken}`,
  domain: '.suno.com',
  path: '/',
  sameSite: lax
});
for (const key in this.cookies) {
  cookies.push({
    name: key,
    value: `${this.cookies[key]}`,
    domain: '.suno.com',
    path: '/',
    sameSite: lax
  })
}
await context.addCookies(cookies);

Possible Solutions

1. Refresh token before browser launch: Call keepAlive() immediately before launching browser to ensure fresh JWT
2. Add more cookie attributes: Include secure: true, httpOnly: false based on actual Suno requirements
3. Handle redirects: Detect the sign-in redirect and retry with refreshed authentication
4. Debug cookie state: Log the actual cookies being set and compare with working browser session
5. Wait for authentication: Add explicit wait for authenticated state after navigation

Additional Notes

• This may be related to recent Suno frontend changes
• The CLERK_BASE_URL recently changed from https://clerk.suno.com to https://auth.suno.com
• The authentication flow may have additional requirements not captured in the current implementation

Help Wanted

Has anyone else encountered this issue? Any insights on:

• Required cookie attributes for Suno's frontend authentication?
• Changes to Suno's authentication flow?
• Successful workarounds for macOS Silicon specifically?

[zach-fau]

Hey, I fixed this today. https://github.com/zach-fau/suno-api I'm maintaining a fork over here on my repo. Check out the changelog if you're interested, but it works now. @0xluk