Feature request: persistent piloted-Chrome profile for hCaptcha solver (`--captcha-profile-dir`)

[jmoranii]

Problem

Every suno generate invocation spawns a fresh piloted Chrome to solve hCaptcha. Since the piloted profile is ephemeral — no persistent suno.com session — Suno's hCaptcha flow surfaces a Google OAuth popup ("Continue as <user>") that requires a manual click before the solver can proceed. The CLI's log says it's headless, but in practice the OAuth popup forces a visible Chrome window with focus stolen from whatever the user is doing.

Repro

1. brew install paperfoot/tap/suno (0.5.7)
2. suno auth --login (succeeds via Chrome cookie extraction; Pro Plan, Clerk session healthy)
3. suno generate --title "test" --tags "edm" --lyrics-file ./lyrics.txt --wait --download ./out/
4. A visible Chrome window opens with the Suno landing page and a Google "Continue as <user>" popup → user must click to proceed
5. Re-run step 3 from a fresh shell → window re-opens, same popup, same manual click required

Cookie-only commands (credits, list, info, status) all work silently — the issue is exclusively the generation-time captcha flow.

Why it matters

This blocks fully unattended workflows:

• Agentic coding-agent integration — e.g. invoking suno-cli from a Claude Code / Cursor / Aider background job; the agent can't click the popup
• Batch generation — N songs back-to-back means N popup clicks; defeats the point of --wait
• Remote / SSH / headless servers — the OAuth popup never reaches a user who isn't physically at the desktop
• Repeat casual use — even just 3–5 songs in a session, the popup-stealing-focus friction accumulates fast

Proposed fix

Persistent piloted-Chrome profile. First invocation: profile is empty, popup appears, user clicks once. Second invocation onward: piloted Chrome reuses the profile dir, the suno.com session is already authed, hCaptcha solver runs silently (or with a much less interactive challenge).

CLI shape:

suno generate ... --captcha-profile-dir ~/.config/suno/captcha-profile/

Or as a sticky config key:

suno config set captcha_profile_dir ~/.config/suno/captcha-profile/

Could also default to ${XDG_CONFIG_HOME:-~/.config}/suno/captcha-profile/ on first run with no flag needed, similar to how the auth state is already cached at ~/.config/suno/.

Alternatives considered

• --no-captcha --token <solved> works but requires manual or 2Captcha-style external solving per call (paid, new account).
• Third-party Suno API proxies (sunoapi.org, AceData) bypass captcha but defeat the entire membership-credits value prop of this CLI.
• A persistent piloted profile feels like the lowest-friction native option that preserves "use my Suno membership."

Env

• macOS 14.x (Darwin 23.6.0), Apple Silicon
• suno-cli 0.5.7 (Homebrew, latest)
• Chrome stable; main profile already logged into suno.com via Google SSO
• Auth: Pro Plan, Clerk session refresh working; only generation-time captcha is interactive

Bonus context

Hit upstream schema drift on cover today (HTTP 422 — Suno added a required title to the cover-params body, CLI doesn't send one). Unrelated to captcha but worth flagging as a separate issue if not already known — happy to file separately.

[ccmagia2-gif]

This reads like a state problem more than a captcha problem. I have had better results treating the browser as sticky state: persist the profile dir once, then reuse it so the Suno session and cookies survive between generate runs. Otherwise every invocation replays the Google OAuth "Continue as ..." step and the solver starts from zero again. The same pattern is what makes a persistent browser-act profile useful: one interactive login, then later runs stay quiet instead of stealing focus every time.

[jmoranii]

Amending my own report after reading the v0.5.7 source — the proposed fix is a no-op, and the real cause is elsewhere.

I went through src/captcha.rs at the v0.5.7 tag (200a384) and need to correct the framing of this issue.

The persistent piloted-Chrome profile I asked for already exists. ensure_chrome_running() already launches Chrome with a durable --user-data-dir under directories::ProjectDirs(...).data_dir()/chrome-profile, created with create_dir_all and reused across invocations (captcha.rs:66-69, :79; the docstring at :57-58 and the comment at :327 both state it's persistent, and the module header at :12 notes the instance is reused across calls). So a --captcha-profile-dir flag or sticky config key would be a no-op — the profile is already persistent and reused. My original "Proposed fix" was wrong; please disregard it.

The actual cause of the per-generation Google OAuth popup is the deliberate per-call cookie wipe. In render_and_execute(), every call issues Network.clearBrowserCookies (captcha.rs:331-337) — intentionally, per the comment at :327-330, to stop stale Clerk/analytics duplicate cookies from tripping an HTTP 431 on suno.com/create before hCaptcha loads. It then re-injects only the narrow whitelist from is_captcha_cookie() (:618-630), pulled live from the user's main browser via rookie.

Net effect: the persistent profile is deliberately neutralized on every call, and the re-injected subset is evidently insufficient for Clerk's Google-SSO to re-establish a session silently — so Suno surfaces the "Continue as <user>" account chooser on every generation. Persisting the profile dir can't fix this, because the cookies in it are cleared on each call by design.

Reframed request: not "add a persistent profile" (already done), but "let the Clerk/Google-SSO session re-establish silently across calls." Concretely that likely means preserving the specific Clerk handshake cookie(s) across invocations instead of the blanket clearBrowserCookies — i.e. trimming only the offending analytics/duplicate cookies that cause the 431, rather than clearing everything. I recognize the blanket clear was a deliberate 431 workaround (:329), so this is a real tradeoff rather than an oversight — which is exactly why it needs a maintainer call and not a naive "don't clear cookies" patch.

Happy to test patches against a Pro Plan / Google-SSO account (the popup repros 100% here — macOS, Chrome stable). If useful, I can also capture the exact cookie set present on a silent vs interactive suno.com/create load to narrow down which cookie(s) gate the silent path.

(The cover HTTP 422 schema-drift I noted as bonus context is unrelated to this and still stands — happy to split it into its own issue whenever that's useful.)