jackwener/OpenCLI · error · AuthRequiredError

linux.do requires an active signed-in browser session

Error message

linux.do requires an active signed-in browser session

What it means

fetchLinuxDoJson drives the site through a local browser session; when the browser reports HTTP 401 or 403, the CLI throws AuthRequiredError because linux.do rejected the request as unauthenticated. This means the user's Discourse login cookie/session is missing, expired, or lacks permission for the endpoint. The library treats authentication as a prerequisite for any feed access, so it fails fast with an auth-specific error instead of a generic HTTP error.

Source

Thrown at clis/linux-do/feed.js:103

      try { data = await res.json(); } catch {}
      return {
        ok: res.ok,
        status: res.status,
        data,
        error: data === null ? 'Response is not valid JSON' : '',
      };
    } catch (error) {
      return {
        ok: false,
        error: error instanceof Error ? error.message : String(error),
      };
    }
  })()`);
    if (!result) {
        throw new CommandExecutionError('linux.do returned an empty browser response');
    }
    if (result.status === 401 || result.status === 403) {
        throw new AuthRequiredError('linux.do', 'linux.do requires an active signed-in browser session');
    }
    if (!result.ok) {
        throw new CommandExecutionError(result.error || `linux.do request failed: HTTP ${result.status ?? 'unknown'}`);
    }
    if (result.error) {
        throw new CommandExecutionError(result.error, 'Please verify your linux.do session is still valid');
    }
    return result.data;
}
function findMatchingTag(records, value) {
    const raw = value.trim();
    const normalized = normalizeLookupValue(value);
    return /^\d+$/.test(raw)
        ? records.find((item) => item.id === Number(raw)) ?? null
        : records.find((item) => normalizeLookupValue(item.name) === normalized)
            ?? records.find((item) => normalizeLookupValue(item.slug) === normalized)
            ?? null;
}

View on GitHub (pinned to 49907e53dc)

Solutions

Open linux.do in the automated browser and sign in so a fresh session cookie exists, then retry the command
Run `opencli linux-do tags` or a plain `opencli linux-do feed` to verify the session works before narrowing by tag/category
If the browser profile is wrong or headless, reconfigure the CLI to use a profile with a valid login
Check whether the target tag/category is private and requires a higher trust level on linux.do

Example fix

// before (shell)
opencli linux-do feed --category 94   // AuthRequiredError: requires active signed-in browser session
// after (shell)
# sign in to linux.do in the browser the CLI drives, then:
opencli linux-do feed --category 94

Defensive patterns

Strategy: try-catch

Validate before calling

// Probe session health before fetching the feed
import { execCommand } from './browser-runner.js'; // the CLI's browser wrapper
const probe = await execCommand(`(async () => {
    const r = await fetch('https://linux.do/session/current.json');
    return { status: r.status };
})()`);
if (!probe || probe.status === 401 || probe.status === 403) {
    throw new Error('Sign in to linux.do in the automated browser before running feed commands');
}

Type guard

function hasAuthenticatedBrowserResult(result) {
    return Boolean(result) && typeof result === 'object' &&
        result.status !== 401 && result.status !== 403;
}

Try / catch

import { AuthRequiredError } from '@jackwener/opencli/errors';
try {
    const topics = await data();
} catch (err) {
    if (err instanceof AuthRequiredError) {
        console.error('linux.do session missing/expired. Open the automated browser and sign in, then retry.');
        process.exitCode = 2;
    } else {
        throw err;
    }
}

Prevention

Keep the automated browser profile persistently logged in to linux.do
Run a cheap session probe (e.g. /session/current.json) before long feed operations
Re-authenticate proactively when the session has been idle for weeks
Avoid logging out or clearing cookies in the browser profile the CLI uses

When it happens

Trigger: Calling any command backed by fetchLinuxDoJson (data, subData via `linux-do feed` with any --view/--tag/--category combination) when the browser fetch returns status 401 or 403: logged-out browser profile, expired linux.do session cookie, Cloudflare/Discourse blocking the automated browser, or accessing a restricted category/tag.

Common situations: User never signed into linux.do in the browser profile the CLI automates; session expired after weeks of inactivity; user logged out or rotated cookies; site tightened anti-bot measures; private category requires elevated trust level.

Related errors

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