Config

The keys of the object that cora.config.ts exports and cora.config.json holds. A key under another, such as policy.failOn, sits in that key’s object, and targets[].crawl is a key of a crawl in targets. Configuration shows how to write the file.

A setting can take its value from a flag, its environment variable, the user config or the project’s config, and otherwise from its default. Which value wins gives the order they apply in. Each of the two files holds only the keys of its own reference page.

A results file records the config’s hash as configHash, and each key’s In configHash says whether its value changes the hash. A function, such as browser.setup, changes it only by being there or not. The shards of one run must share it, as Sharding says.

Example

A cora.config.ts that sets each key below but $schema:

cora.config.ts

import { defineConfig } from '@vispero/cora/config';

export default defineConfig({
  // The app: where it answers, how `cora scan` starts it, and whether its builds carry source stamps.
  baseUrl: 'http://localhost:4173',
  server: {
    command: 'npm run build && npm run preview',
    url: 'http://localhost:4173',
    timeout: 120_000,
    reuseExistingServer: false,
  },
  sourceStamps: true,

  // The pages to scan: paths against `baseUrl`, and a crawl from a start page.
  targets: [
    '/',
    '/pricing',
    { crawl: '/docs/', maxPages: 50, maxDepth: 2, exclude: ['/logout'], ignoreRobotsTxt: false },
  ],

  // Which rules count, and the violations that fail the gate.
  rules: {
    standard: 'WCAG 2.2 AA',
    bestPractices: true,
    overrides: { 'axe/region': 'off', '1.4.6': 'on', forms: 'report' },
  },
  policy: { failOn: 'serious' },

  // The browser: the session it signs in with, the locale and time zone pages load in, and whether
  // it loads a page whose certificate your machine does not trust.
  browser: {
    storageState: '.auth/state.json',
    async setup(context) {
      await context.addCookies([
        { name: 'consent', value: 'accepted', url: 'http://localhost:4173' },
      ]);
    },
    locale: 'en-US',
    timezone: 'America/New_York',
    ignoreHTTPSErrors: false,
    // How long `setup` may run, in milliseconds; this is the default.
    setupTimeout: 60_000,
  },

  // How each page is visited: what it waits for, what it leaves out, and how long it may take.
  page: {
    settle: { quietWindow: 500, timeout: 5000, requestTimeout: 3000 },
    waitFor: (page) => page.getByRole('main').waitFor(),
    exclude: ['#chat-widget'],
    timeout: 60_000,
    retries: 1,
  },

  // Options for the pages whose route matches a pattern, over those above.
  routes: [
    {
      pattern: '^/admin/',
      page: { waitFor: '#app', exclude: [] },
      rules: { bestPractices: false },
    },
  ],
});

$schema

• Type: string
• In configHash: no

The JSON Schema an editor validates cora.config.json against and completes its keys from. Name the schema your installed cora ships by its path from the config’s directory, such as ./node_modules/@vispero/cora/schemas/cora-config/v1.json, so the editor reads the schema of the version you installed, whatever it is, and downloads nothing; cora init writes that path where it finds cora installed. Where none is, such as in a project that runs cora through npx, it writes the schema in the docs of its own minor, https://cora.vispero.com/docs/<minor>/schemas/cora-config/v1.json, such as 0.6 for cora 0.6.2. Change the minor when the cora you run moves to another, and change it to the path once you install cora, since cora init leaves a config it finds as it is. VS Code downloads the schema once you trust cora.vispero.com: its warning that the location is untrusted offers the quick fix Configure Trusted Domains. Nothing in CORA acts on it: the cora that loads the config checks the config against its own schema. cora.config.ts needs none, since defineConfig types it.

baseUrl

• Type: string
• In configHash: yes
• Environment: CORA_BASE_URL
• Command line: cora scan --base-url

The app’s address, an absolute http or https URL. A target given as a path, or a crawl’s start, resolves against it as a link on that page would: with http://localhost:5173/app/, /pricing names http://localhost:5173/pricing and pricing names http://localhost:5173/app/pricing. cora scan --base-url replaces it, and cora-mcp’s scan_url resolves a path against it too. With none set, a target given as a path fails with target.invalid. Its origin, its scheme, host and port, is the app’s: an issue on a page of that origin is identified by the page’s path alone, so the app’s issues are the same on localhost and on a preview host each run names here, and an issue on any other page, or on every page with none set, by the page’s host and path, so two sites’ issues stay apart.

targets

• Type: array of strings or objects
• Default: []
• In configHash: yes
• Environment: none
• Command line: cora scan [targets...], cora scan --crawl, cora scan --crawl-max-pages, cora scan --crawl-max-depth, cora scan --crawl-exclude, cora scan --crawl-ignore-robots-txt

The pages cora scan scans, in order, when its command line names none; targets on the command line replace the whole list. Each is an absolute http or https URL, a path resolved against baseUrl, or a crawl from a start page. A page that several targets reach is scanned once. With no targets here or on the command line, cora scan fails with target.invalid, as it does for a URL of another scheme or a path with no baseUrl.

targets[].crawl

• Type: string
• Required: yes
• In configHash: yes
• Command line: cora scan --crawl

The page the crawl starts from: an absolute http or https URL, or a path resolved against baseUrl. The crawl follows the links (<a href>) in each page it visits, breadth-first, to http and https pages on this page’s host and port, ignoring a link’s fragment, and scans each page it reaches.

targets[].maxPages

• Type: integer
• Default: 25
• In configHash: yes
• Command line: cora scan --crawl-max-pages

The most pages the crawl takes in, its start page included, a positive integer: those it scans, and those a site’s robots.txt disallows, which the results list as not scanned. Once it has found that many, it follows no more links, and cora scan notes that it stopped at this limit.

targets[].maxDepth

• Type: integer
• Default: 2
• In configHash: yes
• Command line: cora scan --crawl-max-depth

The most links the crawl follows away from its start page, a non-negative integer: 0 visits the start page alone, and 1 the start page and the pages it links to. A crawl that stops at it with links left to follow is noted by cora scan.

targets[].exclude

• Type: array of strings
• In configHash: yes
• Command line: cora scan --crawl-exclude

Regular expressions, in JavaScript’s syntax, for links the crawl never follows, such as /logout, to keep it off links that sign out or change data. Each is tested unanchored and case-sensitively against a link’s absolute URL with its credentials replaced by REDACTED, as results files store it. The crawl also skips a page that a redirect lands on when one matches it. A pattern that does not compile fails with config.invalid.

targets[].ignoreRobotsTxt

• Type: boolean
• Default: false
• In configHash: yes
• Command line: cora scan --crawl-ignore-robots-txt

Whether the crawl follows links that their site’s robots.txt disallows. Left off, the crawl reads robots.txt on each origin its links lead to but the origin of baseUrl, and follows no link it disallows for CORA, as the scanning guide describes: https://cora.vispero.com/docs/scanning/#crawls-and-robotstxt. The results list each such page as not scanned, under disallowed-by-robots, so the gate is incomplete unless new issues fail it. The start page, and a page a redirect lands on, are scanned whatever robots.txt says, but in a sharded run a landing page it disallows that another shard owns is scanned by neither shard, and the run is incomplete. Turn it on for a site you own outside baseUrl, such as staging on another origin; cora scan --crawl-ignore-robots-txt turns it on for the crawls on the command line.

rules

• Type: object
• In configHash: yes

Which rules count, for cora scan and cora-mcp’s scans alike: the conformance standard whose rules run, whether best practices run, and overrides that turn rules on, off or to report by rule ID, WCAG success criterion, category or engine. Each applies to every page, and an entry of routes sets its own for the pages it matches. cora scan --only and --skip and cora-mcp’s rules argument narrow a run’s rules, and never add one. Every rule CORA knows is either in the default set, which Vispero keeps, or outside it, such as an experimental or deprecated axe-core rule: the standard, best practices and broad overrides choose among the rules in the default set, and a rule outside it runs only where an override names it by its ID. The rules reference lists every rule with its level, its category and whether it is in the default set: https://cora.vispero.com/docs/reference/rules/

rules.standard

• Type: “WCAG 2.0 A”, “WCAG 2.0 AA”, “WCAG 2.0 AAA”, “WCAG 2.1 A”, “WCAG 2.1 AA”, “WCAG 2.1 AAA”, “WCAG 2.2 A”, “WCAG 2.2 AA”, “WCAG 2.2 AAA”, “Section 508”, “EN 301 549 V3.2.1” or “EN 301 549 V4.1.1”
• Default: "WCAG 2.2 AA"
• In configHash: yes
• Environment: none
• Command line: none

The conformance standard whose rules in the default set run: WCAG 2.0 A, WCAG 2.0 AA, WCAG 2.0 AAA, and the same levels of 2.1 and 2.2, or Section 508, EN 301 549 V3.2.1 or EN 301 549 V4.1.1. A WCAG standard covers its level and the levels below it, in its version and the versions before it, so WCAG 2.1 AA runs the rules of 2.0 and 2.1 at A and AA; a rule of a criterion that WCAG 2.2 made obsolete, 4.1.1 Parsing, runs only under 2.0 and 2.1. Section 508 and EN 301 549 name the WCAG standard their web content requirements take: Section 508 runs WCAG 2.0 AA’s rules, as the Revised 508 Standards incorporate WCAG 2.0 A and AA, EN 301 549 V3.2.1 runs WCAG 2.1 AA’s, and EN 301 549 V4.1.1, as ETSI published it, runs WCAG 2.2 AA’s; CORA checks only the WCAG part of either standard. Only the config file sets it.

rules.bestPractices

• Type: boolean
• Default: true
• In configHash: yes
• Environment: none
• Command line: none

Whether the best practices in the default set run: rules that check what no WCAG success criterion requires, such as axe/region. Only the config file sets it.

rules.overrides

• Type: object of “on”, “off” or “report”
• Default: {}
• In configHash: yes
• Environment: none
• Command line: none

Settings for the rules a selector names, which win over standard and bestPractices: on runs them, off stops them, and report runs them and shows their findings in a section of their own without ever failing the gate. A selector is a rule ID, such as axe/region; a WCAG success criterion, such as 1.4.3, for every rule that checks it; a category, such as forms; or an engine’s rules, such as axe/*. Where several keys name a rule, the most specific decides, in that order: rule ID, criterion, category, engine. A criterion, a category or an engine reaches only the rules in the default set, so only a rule’s ID turns on a rule outside it, as no standard does, and a key that names only such rules decides none, which CORA warns of as the config loads, naming the IDs to add. Two criteria that name one rule with different settings, and an ID or a criterion that names no rule CORA knows, fail with config.invalid; an ID under ai/ goes unchecked.

policy

• Type: object
• In configHash: yes

How the gate judges the new violations a run finds: those the project’s baseline, cora.baseline.json, does not accept. The gate’s verdict sets the exit code of cora scan and cora report merge.

policy.failOn

• Type: “critical”, “serious”, “moderate” or “minor”
• Default: "minor"
• In configHash: yes
• Environment: CORA_POLICY_FAIL_ON
• Command line: none

The lowest severity whose new violations fail the gate: critical, serious, moderate or minor, most severe first. serious fails on new critical and serious violations alone, and minor on every new violation. A failed gate makes cora scan and cora report merge exit with code 1. Needs-review results never fail it.

browser

• Type: object
• In configHash: yes

How the browser signs in before it scans pages behind a sign-in, from a Playwright storageState file, with a setup function, or both, the file loading first, the locale and the time zone its pages load in, and whether it loads a page whose certificate it does not trust. cora-mcp’s browser signs in, and loads its pages, the same way. Left out, the browser starts with no cookies or local storage, its pages load in the en-US locale and the UTC time zone, whatever the machine’s own, and a page whose certificate it does not trust fails to load.

browser.storageState

• Type: string
• In configHash: yes
• Environment: CORA_BROWSER_STORAGE_STATE
• Command line: none

A Playwright storage-state file whose cookies and local storage the browser starts with, as a path relative to the project root, the directory that holds the config file. It can be the file a Playwright authentication setup writes, or one saved by signing in by hand with npx playwright codegen --save-storage=<file>. A file that does not exist fails with signin.storage-state-not-found. Keep it out of version control: it holds session cookies.

browser.setup

• Type: function
• In configHash: yes
• Environment: none
• Command line: none

A function that signs the browser in. It receives Playwright’s BrowserContext and runs once per context, after storageState loads and before the first target: once per cora scan run, and each time cora-mcp’s browser starts. It can fill in a sign-in page, or call context.addCookies, context.setExtraHTTPHeaders or context.setHTTPCredentials; read secrets from environment variables rather than the config. Make it throw when sign-in fails, such as by waiting for the signed-in page: an error it throws fails with signin.setup-failed, as does a setup that outlasts setupTimeout, or cora-mcp’s time limit. Its second argument carries a signal that aborts once setup has to stop, as the time limit passes or the run is cancelled: pass it to fetch, or to setTimeout from node:timers/promises, so what setup started ends with it. A setup that ignores the signal goes on running after CORA stops waiting for it, and a timer or a request of its own can keep the process open. Only cora.config.ts can set it.

browser.locale

• Type: string
• Default: "en-US"
• In configHash: yes
• Environment: none
• Command line: none

The locale every page loads in, as a BCP 47 language tag, such as fr-FR: what navigator.language and each request’s Accept-Language header say, and how the page’s dates and numbers are formatted. A worker the page starts formats as it says too, but reads navigator.language from the machine, which LANGUAGE sets on Linux. Pages load in it whatever the machine’s own locale, so a scan finds the same on every machine; set it to scan the page its visitors in another locale see. A text that is not a well-formed tag, such as en_US, fails with config.invalid. Only the config file sets it.

browser.timezone

• Type: string
• Default: "UTC"
• In configHash: yes
• Environment: none
• Command line: none

The time zone every page loads in, as an IANA time zone name, such as Europe/Paris or America/New_York: the time zone of the page’s dates and times. Pages load in it whatever the machine’s own time zone, so a scan finds the same on every machine. Any name or alias Node.js knows works, such as Asia/Kolkata or Etc/UTC; a name Node.js does not know, or an offset such as +01:00, fails with config.invalid. Only the config file sets it.

browser.ignoreHTTPSErrors

• Type: boolean
• Default: false
• In configHash: no
• Environment: none
• Command line: none

Whether the browser loads a page whose HTTPS certificate it does not trust, such as a dev server’s self-signed one, as Playwright’s option of this name does, for cora scan and cora-mcp alike, and whether cora scan’s wait for server.url counts such a certificate’s answer as ready. Off, such a page fails to load, as navigation-failed, and such a server fails with server.timed-out. Turn it on only for an app you serve yourself: the browser then loads every page, on any host, without checking its certificate. Only the config file sets it.

browser.setupTimeout

• Type: integer
• Default: 60000
• In configHash: no
• Environment: CORA_BROWSER_SETUP_TIMEOUT
• Command line: none

How long setup may run, in milliseconds: a positive integer up to a day, 86400000. A setup still running then fails with signin.setup-failed, naming this setting, and the browser closes. Raise it for a sign-in that takes longer, such as one that waits on a single-sign-on provider, or, on a slow connection, in your user config. cora-mcp opens its browser, setup included, within mcp.callTimeout too, and the sooner of the two ends it. The user config’s browser.setupTimeout replaces this in every project, and CORA_BROWSER_SETUP_TIMEOUT overrides both.

page

• Type: object
• In configHash: yes

How CORA treats each page it scans or visits: how it waits for the page to settle, what it waits for first, which of its elements no rule evaluates, how long a visit may take, and how often a failed visit is tried again. Each option applies to every page, and an entry of routes sets its own value for the pages it matches.

page.settle

• Type: object
• In configHash: yes

How CORA waits for a page to settle before it scans it: until the page and its same-origin iframes have loaded, its documents go quietWindow milliseconds without a change to the DOM and its requests as long without one in flight, its fonts are ready and its animations that end have ended, or until timeout passes, when CORA scans the page as it is and its results record that the page did not settle.

page.settle.quietWindow

• Type: integer
• Default: 500
• In configHash: yes
• Environment: none
• Command line: none

How long a page’s documents must go without a change to the DOM, attributes included, and its requests without one in flight, before CORA counts the page settled, in milliseconds: a positive integer up to a day, 86400000. Raise it for a page that pauses between bursts of rendering for longer, such as behind a debounce. Only the config file sets it.

page.settle.timeout

• Type: integer
• Default: 5000
• In configHash: yes
• Environment: none
• Command line: none

How long CORA waits for a page to settle before it gives up and scans the page as it is, its results recording that the page did not settle, in milliseconds: a positive integer up to a day, 86400000. Raise it for a page whose content keeps arriving for longer. The wait counts toward page.timeout. Only the config file sets it.

page.settle.requestTimeout

• Type: integer
• Default: 3000
• In configHash: yes
• Environment: none
• Command line: none

How long one request may stay in flight and still hold settling, in milliseconds: a positive integer up to a day, 86400000. Settling waits for the requests a page makes for documents, stylesheets, scripts, fonts, images and the data its scripts fetch, and stops waiting for one open longer, such as a long poll; event streams, WebSockets and media never hold it. Raise it, with timeout above it, for a page whose content arrives after a slower request, or wait for that content with waitFor. Only the config file sets it.

page.waitFor

• Type: string or function
• In configHash: yes
• Environment: none
• Command line: none

What CORA waits for in a page once it loads, before it waits for the page to settle: a CSS selector, which holds the scan until an element in the main document matches it, visible or not, or, in cora.config.ts only, a function that receives Playwright’s Page and resolves once the page is ready, such as (page) => page.getByRole('main').waitFor(); it also receives { signal }, which aborts once CORA stops waiting, for a wait that takes one. Left out, CORA waits only for the page to settle. The wait counts toward page.timeout, and a page not ready within it is recorded timed-out. A function that throws, or a selector that is not valid CSS, leaves the page unscanned, recorded not-ready. Only the config file sets it.

page.exclude

• Type: array of strings
• Default: []
• In configHash: yes
• Environment: none
• Command line: none

CSS selectors for elements no rule evaluates, each with everything inside it, such as a third-party chat widget, an embedded player or a consent banner the project does not own. Each is matched in a page’s main document: name an iframe to leave out the document it shows, or a shadow host to leave out its shadow tree. On a page where one matches, the rest of the page is scanned, and each engine’s coverage is partial with the reason excluded-by-config, naming the selectors that matched; the baseline still counts the page as scanned completely, so a violation it accepts on an element left out reads as fixed, and cora baseline update drops it. A selector that matches nothing on a page is allowed there. One that is not valid CSS, or that matches the page’s root element, such as html, which would leave out the whole page, fails the scan with scan.invalid-scope, naming it, on the first page it is met: to scan nothing on a route, turn its rules off in its rules.overrides, or keep a crawl off it with the crawl’s exclude. An entry of routes that sets its own list replaces this one on the pages it matches, rather than adding to it. cora-mcp’s scans leave the same elements out, beside the exclude an agent passes, and an agent’s include that matches an element on or inside one fails with scan.invalid-scope. Only the config file sets it.

page.timeout

• Type: integer
• Default: 60000
• In configHash: no
• Environment: CORA_PAGE_TIMEOUT
• Command line: cora scan --page-timeout

How long one visit of a page may take, from opening it to closing it, loading, waiting for and scanning it included, in milliseconds: a positive integer up to a day, 86400000. A page that takes longer is recorded timed-out, naming this setting. Raise it for a site that loads slowly, or on a slow machine: cora scan --page-timeout, CORA_PAGE_TIMEOUT and page.timeout in the user config override it, in that order. cora-mcp’s scans also stop at mcp.callTimeout, whichever comes first.

page.retries

• Type: integer
• Default: 0
• In configHash: no
• Environment: CORA_PAGE_RETRIES
• Command line: none

How many more times cora scan visits a page, each time in a fresh tab with the whole of page.timeout, when a visit fails to load it or runs out of time: a non-negative integer. At 0, a page that fails once is recorded as failed. cora-mcp’s scans never retry: the agent decides whether to scan again. CORA_PAGE_RETRIES overrides it.

routes

• Type: array of objects
• Default: []
• In configHash: yes
• Environment: none
• Command line: none

Options for the pages whose route matches a pattern, which win over page there. A page’s route is its URL without its origin, its path, query and fragment, as results files store it, such as /docs/intro?lang=en. Every entry whose pattern matches a page applies, in order: a later entry’s option wins over an earlier one’s, and an option no matching entry sets keeps the value of page. They apply to cora scan’s targets, the pages a crawl finds and cora-mcp’s scans alike.

routes[].pattern

• Type: string
• Required: yes
• In configHash: yes

A regular expression, in JavaScript’s syntax, tested unanchored and case-sensitively against a page’s route, its URL without its origin, such as ^/docs/ or /checkout. A pattern that does not compile fails with config.invalid.

routes[].page

• Type: object
• In configHash: yes
• Keys: settle, waitFor, exclude, timeout, retries, each as page has it

The page options this entry sets for the pages it matches, each as page has it but with no default: an option it leaves out keeps the value of an earlier matching entry, or of page. Its exclude replaces the earlier list rather than adding to it, so [] leaves nothing out on those pages.

routes[].rules

• Type: object
• In configHash: yes
• Keys: standard, bestPractices, overrides, each as rules has it

Which rules count on the pages this entry matches, each key as rules has it but with no default, applied after rules and the earlier matching entries: it decides each rule one of its own keys reaches, an override that reaches the rule as rules.overrides says, or its standard or bestPractices for a rule in the default set, and every other rule keeps its earlier setting.

sourceStamps

• Type: boolean
• In configHash: no
• Environment: CORA_SOURCE_STAMPS
• Command line: none

Whether CORA’s build plugin, such as @vispero/cora/vite in the app’s Vite config or @vispero/cora/webpack in its webpack config, writes source stamps: the data-cora-source attribute on each host element, so a finding on the element names its file and line. true stamps every build and development, and false stamps neither. Left out, development stamps, such as Vite’s dev server, the development mode of webpack, Rspack and Rsbuild, or a Rollup or Rolldown watch, and a build does not, so a production build carries no stamps unless asked; under esbuild, which tells a plugin nothing of development, it stamps nothing. CORA_SOURCE_STAMPS replaces it, 1 or true and 0 or false, such as for one build in CI. It does not switch an Angular app’s source locations, which Angular’s compiler writes in the builds whose tsconfig turns them on.

server

• Type: object
• In configHash: no

The app’s server, which cora scan starts before it scans and stops once it has, as Playwright’s webServer does, so a scan in CI needs no server started by hand. cora scan runs command in the project root, waits until url answers, scans, then ends the command and what it started, whether the scan passes, fails or is interrupted; as with Playwright, a process that leaves the command’s process group, such as one started detached, or on Windows one whose parent has already exited, keeps running. A server already answering at url fails the scan with server.already-running, unless reuseExistingServer is on. The command runs with CORA_SOURCE_STAMPS set to 1, so an app it builds with CORA’s build plugin carries source stamps and findings name their source lines, unless sourceStamps, or CORA_SOURCE_STAMPS over it, is false. cora-mcp never starts it: start the app yourself before a coding agent scans it. Left out, cora scan scans whatever answers at its targets.

server.command

• Type: string
• In configHash: no
• Environment: CORA_SERVER_COMMAND
• Command line: none

The command that starts the app’s server, which the platform’s shell runs in the project root, the directory that holds the config file: /bin/sh on Linux and macOS and cmd.exe on Windows, as a package.json script runs, such as npm run build && npm run preview. It needs url beside it, and server starts nothing without it. Its output goes to the log, at debug. A command that exits, or cannot start, before url answers fails with server.exited, naming its exit code or signal and the end of its error output.

server.url

• Type: string
• In configHash: no
• Environment: CORA_SERVER_URL
• Command line: none

The URL whose answer means the server is ready, an absolute http or https URL, usually baseUrl or a page under it, such as http://localhost:4173. It needs command beside it. cora scan requests it once before it runs the command, then again until it answers with any status below 404: a redirect, or a 401 or 403 from a page behind a sign-in, counts as ready, and a 404 or 5xx from a server still building does not.

server.timeout

• Type: integer
• Default: 60000
• In configHash: no
• Environment: CORA_SERVER_TIMEOUT
• Command line: none

How long cora scan waits for url to answer, from running command, in milliseconds: a positive integer up to a day, 86400000. A server not ready within it fails with server.timed-out, naming this setting and its value, and its processes are ended. Raise it for an app whose build takes longer, or on a slow machine: CORA_SERVER_TIMEOUT and server.timeout in the user config override it, in that order.

server.reuseExistingServer

• Type: boolean
• Default: false
• In configHash: no
• Environment: CORA_SERVER_REUSE_EXISTING_SERVER
• Command line: none

Whether cora scan scans a server that already answers at url, starting none and leaving that server running after the scan, rather than failing with server.already-running. Left off, a scan never scans a server left running by something else, such as an earlier job on a CI runner. Turn it on in your user config, or with CORA_SERVER_REUSE_EXISTING_SERVER, to scan a server you keep running yourself while CI keeps it off.