jackwener/OpenCLI · error · AuthRequiredError

LinkedIn connect requires an active signed-in LinkedIn brows

Error message

LinkedIn connect requires an active signed-in LinkedIn browser session.

What it means

After navigating to the profile and probing it, the command runs assessProfileSafety. When the probe concludes the page is showing LinkedIn's auth/login wall (blockReason === 'auth_required'), it throws AuthRequiredError rather than attempting to interact with a page the automation cannot see correctly.

Source

Thrown at clis/linkedin/connect.js:434

        const expectedName = requireStringArg(args, 'expected-name', '--expected-name');
        const note = clampNote(args.note || '');

        await page.goto(profileUrl);
        await page.wait(6);
        let probe = await probeProfile(page, expectedName);
        // The name resolves early (from document.title), but the profile action
        // buttons (Connect / Message / Pending) render later. Keep probing until
        // the action state has resolved, not merely until the name is visible.
        for (let attempt = 0; attempt < 8; attempt += 1) {
            const resolved = probe?.name
                && (probe.connectAvailable || probe.alreadyConnected || probe.pending || probe.moreAvailable);
            if (resolved) break;
            await page.wait(2);
            probe = await probeProfile(page, expectedName);
        }
        const safety = assessProfileSafety(probe, expectedName, profileUrl);
        if (safety.blockReason === 'auth_required') {
            throw new AuthRequiredError(LINKEDIN_DOMAIN, 'LinkedIn connect requires an active signed-in LinkedIn browser session.');
        }
        if (!safety.ok && safety.safety === 'routine_non_connectable') {
            return [{ status: 'not_connectable', recipient: safety.actualValue, reason: safety.blockReason, profile_url: safety.observedUrl, note_chars: note.length, connectable: false }];
        }
        if (!safety.ok) {
            throw new CommandExecutionError(
                `LinkedIn connect blocked: ${safety.blockReason}`,
                `Expected ${safety.expectedValue}; actual ${safety.actualValue || 'not_visible'} at ${safety.observedUrl || 'url_not_available'}\nButtons: ${(probe?.buttonLabels || []).join(' | ')}`,
            );
        }
        if (!args.send) {
            return [{ status: 'connectable_dry_run', recipient: safety.actualValue, reason: safety.blockReason, profile_url: safety.observedUrl, note_chars: note.length, connectable: true }];
        }
        const inviteHref = probe?.connectHref || '';
        if (inviteHref) {
            // Anchor-based Connect: navigate straight to the invitation route, where the
            // "Add a note?" dialog renders already open.
            const inviteUrl = canonicalizeLinkedInInviteUrl(inviteHref);

View on GitHub (pinned to 49907e53dc)

Solutions

  1. Log in to LinkedIn in the browser session (interactive login or restored profile with valid cookies) and re-run the command
  2. Persist/reuse a browser profile directory so cookies survive across runs
  3. Re-authenticate and complete any LinkedIn security checkpoint before automating
  4. Reduce automation rate / use a stable IP if LinkedIn is challenging the session

Example fix

null
Defensive patterns

Strategy: retry

Validate before calling

// before running, confirm the session cookie is present in the browser profile
const signedIn = await page.evaluate(() => !document.querySelector('a[href*="/checkpoint/"]') && document.querySelector('.global-nav') !== null);
if (!signedIn) throw new Error('LinkedIn session not signed in — authenticate first.');

Type guard

null

Try / catch

try { await runConnect(args); } catch (e) { if (e instanceof AuthRequiredError || String(e.message).includes('signed-in LinkedIn')) { await interactiveLogin(LINKEDIN_DOMAIN); await runConnect(args); } else { throw e; } }

Prevention

When it happens

Trigger: The LinkedIn session cookie expired or was never established, so navigating to the profile redirects to a login challenge; the probe sees the sign-in wall and classifies it as auth_required.

Common situations: Long-running sessions whose LinkedIn cookies expired; running against a fresh browser profile with no logged-in account; LinkedIn forcing re-authentication / security checkpoint; running from an IP that triggers login walls.

Related errors

AI-assisted analysis of jackwener/OpenCLI@49907e53dc (2026-08-29). Data as JSON: /api/errors/9fe075143621d433. Report an issue: GitHub.