Update self-hosted changelog: v0.114.60

.github/workflows/preview-docs.yml

@@ -8,6 +8,7 @@ on:
 
 jobs:
   run:
+    if: github.event.pull_request.head.repo.full_name == github.repository
     runs-on: ubuntu-latest
     permissions:
       pull-requests: write # Only for commenting

fern/products/api-def/openapi/auth.mdx

@@ -218,6 +218,8 @@ auth-schemes:
       env: MY_CLIENT_SECRET
 ```
 
+[Set `omit: true` on `username` or `password`](/learn/sdks/reference/generators-yml#usernameomit-passwordomit) to remove it from the generated SDK.
+
 </Accordion>
 <Accordion title="API key">
 

fern/products/api-def/openapi/extensions/availability.mdx

@@ -5,7 +5,7 @@ description: Mark API endpoint availability in OpenAPI with `x-fern-availability
 ---
 
 
-The `x-fern-availability` extension is used to mark the availability of an endpoint within your OpenAPI definition. The availability information propagates into the generated Fern Docs website as visual tags. 
+The `x-fern-availability` extension is used to mark the availability of an endpoint within your OpenAPI definition. The availability information propagates into the generated Fern Docs website as visual tags, SDKs, and [CLIs](/learn/cli-generator/get-started/openapi-extensions#availability-badges).
 
 You can configure the `availability` of sections in your API Reference documentation in your [`docs.yml` file](/learn/docs/configuration/site-level-settings). 
 

fern/products/api-def/openapi/extensions/method-names.mdx

@@ -5,7 +5,7 @@ description: Use `x-fern-sdk-method-name` and `x-fern-sdk-group-name` to finetun
 ---
 
 
-Use the `x-fern-sdk-group-name` and `x-fern-sdk-method-name` extensions to control how endpoints are organized in your SDK.
+Use the `x-fern-sdk-group-name` and `x-fern-sdk-method-name` extensions to control how endpoints are organized in your [SDKs](/learn/sdks/overview/introduction) and [CLIs](/learn/cli-generator/get-started/openapi-extensions).
 
 <Note title="Fern automatically parses `operationId`">
   If no extensions are present, Fern uses your operation ID to generate SDK method names. Format operation IDs as `{tag_name}_{operation_name}` (example: `users_get`) to automatically generate methods like `users.get()`. If the operation ID doesn't start with a tag, Fern uses it directly as the method name.

fern/products/api-def/openapi/extensions/overview.md

@@ -4,7 +4,7 @@ headline: Extensions overview (OpenAPI)
 description: Learn about OpenAPI extensions in Fern. Customize authentication, SDK methods, versioning, and more for better API specs.
 ---
 
-Fern supports a variety of OpenAPI extensions that enhance your API specification and generate higher-quality SDKs. 
+Fern supports a variety of OpenAPI extensions that enhance your API specification and generate higher-quality SDKs and [CLIs](/learn/cli-generator/get-started/openapi-extensions).
 
 You can apply these extensions in two ways: by overlaying them in a separate file or by embedding them directly in your OpenAPI specification. See [Overlays](/learn/api-definitions/openapi/overlays) for more information.
 

fern/products/api-def/openapi/extensions/pagination.mdx

@@ -7,7 +7,7 @@ description: Configure auto-pagination for list endpoints using the x-fern-pagin
 
 <Markdown src="/snippets/pro-plan.mdx"/>
 
-The `x-fern-pagination` extension configures auto-pagination for list endpoints in your OpenAPI specification. [Fern's generated SDKs](/learn/sdks/deep-dives/auto-pagination) provide simple iterators that handle pagination automatically, so SDK users can loop through all results without managing pagination complexity manually.
+The `x-fern-pagination` extension configures auto-pagination for list endpoints in your OpenAPI specification. [SDK](/learn/sdks/deep-dives/auto-pagination) and [CLI](/learn/cli-generator/get-started/openapi-extensions#pagination) users get automatic pagination without managing page tokens manually.
 
 To configure pagination:
 

fern/products/api-def/openapi/overlays.mdx

@@ -7,7 +7,7 @@ description: Use the OpenAPI Overlay Specification to customize your OpenAPI def
 Overlays let you customize your OpenAPI specification without modifying the original file. This is useful when:
 
 - Your API specification is auto-generated from server code
-- You need different configurations for SDKs versus documentation
+- You need different configurations for SDKs, documentation, or [generated CLIs](/learn/cli-generator/get-started/customization#overrides-and-overlays)
 - You want to add Fern configurations like pagination or SDK method names
 - You want to make bulk changes across many endpoints using JSONPath wildcards
 

fern/products/api-def/pages/overrides.mdx

@@ -7,7 +7,7 @@ description: Customize your API definition using a separate overrides file.
 Use an overrides file to customize your OpenAPI, AsyncAPI, or OpenRPC definition without modifying the original spec. This is useful when:
 
 * Your API specification is auto-generated from server code
-* You need different configurations for SDKs versus documentation
+* You need different configurations for SDKs, documentation, or [generated CLIs](/learn/cli-generator/get-started/customization#overrides-and-overlays)
 
 Overrides are available for OpenAPI, AsyncAPI, and OpenRPC specifications.
 

fern/products/cli-api-reference/cli-changelog/2026-05-10.mdx

@@ -0,0 +1,6 @@
+## 5.22.0
+**`(feat):`** Add `fern sdk list` command to list configured and available SDK generators.
+Displays configured SDKs from local fern.yml and available generators from the
+Fern registry. Supports `--language`, `--type`, and `--json` flags.
+
+

fern/products/cli-api-reference/cli-changelog/2026-05-11.mdx

@@ -0,0 +1,26 @@
+## 5.23.1
+**`(fix):`** Fix `fern docs dev` hanging indefinitely on Node.js v26+ on Linux by disabling
+io_uring in the child server process. Node 26 enables io_uring by default in
+libuv, which has a busy-loop bug where worker threads spin on an internal
+eventfd, starving the main event loop.
+
+
+## 5.23.0
+**`(internal):`** Add an opt-in `VerificationStep` to the post-generation pipeline that runs
+`.fern/verify.sh` (when emitted by the generator) inside a language-specific
+`{generatorImage}-validator` container after replay and before any GitHub
+push. A failing script aborts the pipeline before opening a PR and surfaces
+raw stderr through the pipeline logger; a missing script is a silent no-op.
+
+The step is gated on a hidden `--verify` flag for `fern generate`; when
+passed (with `--local` or `--runner`), the local workspace runner sets
+`config.verify.enabled = true` on the pipeline and the configured container
+runtime (`docker` or `podman`) is forwarded to the validator container.
+Remote/Fiddle generation does not honor this flag yet.
+
+
+## 5.22.1
+**`(fix):`** Fix `fern docs dev` failing with pnpm 11 due to esbuild build scripts being blocked by default.
+Writes `onlyBuiltDependencies` config to the bundle folder before installing esbuild.
+
+

fern/products/cli-api-reference/cli-changelog/2026-05-12.mdx

@@ -0,0 +1,17 @@
+## 5.23.3
+**`(fix):`** Property-level `x-fern-audiences` filtering now also applies on the V3 OpenAPI / AsyncAPI /
+OpenRPC import path used by `fern docs dev` and `fern generate --from-openapi`. Inline
+request-body properties, query parameters, inline webhook payload properties, named-type
+properties, `v2RequestBodies`, and the docs `v2Examples` blocks (type-level, request body,
+response body, endpoint-level, `v2Responses`, and webhook payload examples) are now scrubbed
+using the same exclusion semantics as the Fern Definition path. Untagged elements remain
+universal and are never silently removed.
+
+
+## 5.23.2
+**`(fix):`** Suppress Fern's platform `User-Agent` header in generated SDKs when the API definition
+declares a global `User-Agent` header (case-insensitive) under `api.headers`. This
+allows customers to fully override the SDK User-Agent via their Fern Definition without
+the auto-generated `<package>/<version>` value also being emitted.
+
+

fern/products/cli-api-reference/cli-changelog/2026-05-13.mdx

@@ -0,0 +1,30 @@
+## 5.24.0
+**`(internal):`** Plumb `verify`, `verifyRunner`, and `verifyValidatorVersion` flags through
+`GenerationRunner.RunArgs` so the seed runner can invoke
+`PostGenerationPipeline` with `VerificationStep` and exercise the same
+validator-container code path that `fern generate --local --verify` uses.
+No customer-facing CLI behavior change — the flags are opt-in and used only
+by the seed test runner today.
+
+
+## 5.23.6
+**`(fix):`** Fix `fern docs dev` hot reload not working for .mdx file changes. The backend
+now updates the docs definition before notifying the browser to refresh, and
+the reload handler properly recovers from errors instead of silently blocking
+all future reloads.
+
+
+## 5.23.5
+**`(fix):`** Fix SDK generation crashing with `fatal: <sha> is not a valid object`
+when the prior fern-bot PR was squash-merged and its branch deleted.
+The stale `fern-generation-base` tag update is now skipped with a
+warning; the SDK PR still opens.
+
+
+## 5.23.4
+**`(fix):`** Fix allOf composition so inline elements with real constraints (e.g. `pattern`, `minLength`) produce a properly merged type instead of being silently dropped. Also refactored the allOf shortcircuit logic to use a metadata allowlist, which is safer against new OpenAPI fields.
+
+
+**`(fix):`** Fix example generation for allOf compositions to merge base schema fields into property overrides. When an allOf override specifies only `items` without `type: array`, the base schema's type is now correctly inherited, producing properly typed examples instead of null.
+
+

fern/products/cli-api-reference/cli-changelog/2026-05-14.mdx

@@ -0,0 +1,13 @@
+## 5.25.0
+**`(feat):`** Register the new `fernapi/fern-cli` generator in the CLI configuration.
+
+
+## 5.24.2
+**`(fix):`** Fix `fern config migrate` producing wrong file path references in the generated `fern.yml`. Paths from `generators.yml` (relative to the `fern/` directory) are now correctly re-rooted to be relative to the project root where `fern.yml` is created. This also fixes the `docs` `$ref` pointer to use `./fern/docs.yml` instead of `./docs.yml`.
+
+
+## 5.24.1
+**`(chore):`** Propagate Fern `docs:` strings into generated JSON Schemas so editor hovers
+work for schemas served from `schema.buildwithfern.dev`.
+
+

fern/products/cli-api-reference/pages/commands.mdx

@@ -276,12 +276,14 @@ hideOnThisPage: true
 
     <Warning>
     The `--broken-links` and `--strict-broken-links` flags are deprecated. Use the [`broken-links` validation rule](/learn/docs/configuration/site-level-settings#check-configuration) in `docs.yml` instead.
-
-    You can also use the [Fern Dashboard](https://dashboard.buildwithfern.com/) to validate both internal and external links on your live published site.
     </Warning>
 
     Use `fern check` to validate your API definition and Fern configuration, including [`fern.config.json`](/learn/sdks/overview/project-structure#fernconfigjson), `generators.yml`, and `docs.yml`. It checks for broken links, invalid API examples, configuration errors, and more. When all checks pass, the command produces no output.
 
+     Most `fern check` rules — including [`broken-links`](/learn/docs/configuration/site-level-settings#check-configuration) — validate against the navigation tree built from your **local** config and do not crawl your live deployed site or follow external URLs. The exception is the [`missing-redirects` rule](/learn/docs/seo/redirects#catching-missing-redirects), which compares your local navigation against the previously published state and therefore requires `fern login` or `FERN_TOKEN`.
+
+    To check links on a published site, use the link checker in the [Fern Dashboard](https://dashboard.buildwithfern.com/) instead. When all checks pass, the command produces no output.
+
     <CodeBlock title="terminal">
     ```bash
     fern check [--api <api>] [--warnings]

fern/products/cli-generator/authentication.mdx

@@ -0,0 +1,68 @@
+---
+title: Authentication
+description: Configure how generated CLIs authenticate with your API using environment variables, CLI flags, files, or fallback chains.
+availability: beta
+---
+
+<Note title="Early access">
+The CLI generator is in early access. [Reach out](https://buildwithfern.com/book-demo?type=cli) to get started.
+</Note>
+
+Each generated CLI reads authentication credentials from the security schemes declared in your OpenAPI spec. Credentials can come from environment variables, CLI flags, files, or a combination of these through fallback chains.
+
+Without a credential, the CLI still works — you can explore the command tree, view help, and use `--dry-run`.
+
+## Credential sources
+
+The CLI supports several ways to supply credentials, configured at build time.
+
+| Source | Description |
+| --- | --- |
+| Environment variable | Read from an env var (the most common option). |
+| CLI flag | Auto-registered as a `--<flag-name>` global flag. |
+| File | Read trimmed contents from a file path (`~` is expanded). |
+| Literal | Baked into the binary at compile time. |
+| Fallback chain | Try multiple sources in order; first non-empty value wins. |
+
+A typical fallback chain lets the CLI flag override the env var, which in turn overrides a file:
+
+```bash
+# CLI flag takes priority
+box users get-current-user --api-token sk-123
+
+# Otherwise falls back to the environment variable
+export BOX_API_KEY=sk-123
+box users get-current-user
+
+# Otherwise reads from a file
+echo "sk-123" > ~/.box/token
+box users get-current-user
+```
+
+## Supported auth schemes
+
+The CLI supports every scheme type that OpenAPI's `securitySchemes` defines:
+
+| Scheme | How the CLI applies it |
+| --- | --- |
+| Bearer (`http: bearer`) | Sends `Authorization: Bearer <token>`. |
+| API key (`apiKey`) | Sends the key in the configured header (for example, `X-Auth-Token`). |
+| Basic (`http: basic`) | Sends `Authorization: Basic <base64(user:pass)>`. Each field has its own credential source. |
+| OAuth 2 | Treated as bearer — sends `Authorization: Bearer <token>`. |
+
+## Auth strategies
+
+When a spec declares multiple security schemes, the CLI composes them according to one of these strategies:
+
+| Strategy | Behavior |
+| --- | --- |
+| Auto | Default. Infers the right composition from the spec's `security` blocks. |
+| Any | The API accepts any one of the declared schemes. The first scheme with a credential wins. |
+| All | The API requires every scheme simultaneously (for example, HMAC signature plus API key). |
+| Routing | Per-operation dispatch. Each endpoint's `security` block determines which schemes to use. |
+
+Operations that declare `security: []` (an empty list) opt out of authentication entirely — no credentials are sent regardless of what's configured.
+
+## Help output
+
+Every generated CLI includes a dynamically rendered `Authentication:` section in its `--help` output listing every scheme, the expected env var or flag, and whether a credential is detected.

fern/products/cli-generator/cli-generator.yml

@@ -4,4 +4,15 @@ navigation:
       - page: Overview
         path: ./overview.mdx
         slug: overview
-
+      - page: Features
+        path: ./features.mdx
+        slug: features
+      - page: Authentication
+        path: ./authentication.mdx
+        slug: authentication
+      - page: OpenAPI extensions
+        path: ./openapi-extensions.mdx
+        slug: openapi-extensions
+      - page: Customization
+        path: ./customization.mdx
+        slug: customization

fern/products/cli-generator/customization.mdx

@@ -0,0 +1,68 @@
+---
+title: Customization
+description: Customize generated CLIs with overrides, overlays, multi-spec merging, and custom commands.
+availability: beta
+---
+
+<Note title="Early access">
+The CLI generator is in early access. [Reach out](https://buildwithfern.com/book-demo?type=cli) to get started.
+</Note>
+
+A generated CLI can be customized at three levels: the OpenAPI spec it's built from, the configuration that combines multiple specs into a single command tree, and code that adds custom commands alongside the spec-derived ones.
+
+## Overrides and overlays
+
+The CLI generator supports both [overrides](/learn/api-definitions/openapi/overrides) and [overlays](/learn/api-definitions/openapi/overlays) for customizing the OpenAPI spec before the CLI is built. This lets you add Fern extensions, rename parameters, or remove internal endpoints without modifying your original spec.
+
+Overlays follow the [OpenAPI Overlay Specification](https://spec.openapis.org/overlay/v1.0.0.html) and use JSONPath to target elements:
+
+```yaml title="overlay.yaml"
+overlay: 1.0.0
+info:
+  title: CLI customizations
+  version: 1.0.0
+actions:
+  - target: $.paths['/plants'].get
+    update:
+      x-fern-sdk-group-name: plants
+      x-fern-sdk-method-name: list
+  - target: $.paths['/internal/debug']
+    remove: true
+```
+
+When both are present, overrides are applied first, then overlays.
+
+## Multi-spec merging
+
+A single CLI can combine multiple OpenAPI specs into one command tree. This is useful for APIs that split their spec across domains or versions.
+
+Specs can be merged flat (all commands at the top level) or under a namespace prefix:
+
+```rust title="main.rs"
+CliApp::new("my-api")
+    .spec(include_str!("core.yaml"))
+    .spec_under("billing", include_str!("billing.yaml"))
+    .run()
+```
+
+This produces a CLI where core commands live at the top level and billing commands live under a `billing` subcommand:
+
+```bash
+my-api users list          # from core.yaml
+my-api billing invoices list  # from billing.yaml
+```
+
+When a namespace matches a top-level resource in the incoming spec, the CLI hoists that resource's methods into the namespace to avoid repetition (for example, `billing billing invoices list` becomes `billing invoices list`).
+
+## Custom commands
+
+Generated CLIs can include custom commands alongside the spec-derived ones. Custom commands have access to the same API executor, so they can chain multiple API calls into a single workflow.
+
+```rust title="main.rs"
+CliApp::new("my-api")
+    .spec(include_str!("openapi.yaml"))
+    .auth_scheme_env("bearerAuth", "MY_API_TOKEN")
+    .command(whoami_cmd(), whoami_handler)
+    .run()
+```
+