Update stacklok/toolhive to v0.26.0 (#826)

* Update stacklok/toolhive to v0.26.0

Signed-off-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

* Refresh reference assets for toolhive v0.26.0

* Document v0.26.0 user-facing additions

- Note that OAuth 2.0 upstream userInfo is now optional with synthesis mode
  for upstreams without a userinfo endpoint
- Add an "Interactive dashboard" pointer to thv tui from the CLI manage guide
- Document operator.defaultImagePullSecrets for chart-level pull secrets
  and its precedence with per-CR imagePullSecrets

Co-authored-by: claude[bot] <noreply@anthropic.com>

* Edit v0.26.0 doc additions for clarity

- Tighten the thv tui tip and drop the trailing complement-to-CLI line
- Move the tk- prefix next to the synthesized subject and replace "shape"
  with "configuration" in the userInfo synthesis-mode note
- Lift the per-CR imagePullSecrets parenthetical into a list and remove
  redundant phrasing in the operator pull-secret section

Co-authored-by: claude[bot] <noreply@anthropic.com>

---------

Signed-off-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com>
Co-authored-by: claude[bot] <noreply@anthropic.com>

Author: 3 people

.github/upstream-projects.yaml

@@ -35,7 +35,7 @@ projects:
 
   - id: toolhive
     repo: stacklok/toolhive
-    version: v0.25.0
+    version: v0.26.0
     # toolhive is a monorepo covering the CLI, the Kubernetes
     # operator, and the vMCP gateway. It also introduces cross-
     # cutting features that land in concepts/, integrations/,

docs/toolhive/guides-cli/manage-mcp-servers.mdx

@@ -9,6 +9,16 @@ description:
 ToolHive provides visibility into the status of your MCP servers. You can check
 the status of running servers and view their logs using the ToolHive CLI.
 
+:::tip[Interactive dashboard]
+
+To monitor and operate servers from a single live view instead of chaining
+together `thv list`, `thv logs`, and other subcommands, run
+[`thv tui`](../reference/cli/thv_tui.md) to launch the experimental terminal
+dashboard. It shows a real-time server list, streaming logs, a tool inspector,
+and a registry browser. Press `?` for the full key map.
+
+:::
+
 ### List running servers
 
 To see all currently running MCP servers:

docs/toolhive/guides-k8s/auth-k8s.mdx

@@ -735,11 +735,19 @@ spec:
 
 :::note
 
-OAuth 2.0 providers require explicit endpoint configuration and a `userInfo`
-section, unlike OIDC providers which auto-discover these from the issuer URL.
-The `fieldMapping` section maps provider-specific response fields to standard
-user identity fields. For example, GitHub returns `login` instead of the
-standard `name` field.
+OAuth 2.0 providers require explicit endpoint configuration, unlike OIDC
+providers which auto-discover these from the issuer URL. The `userInfo` section
+is optional: when present, the embedded auth server fetches user identity claims
+from the configured endpoint, and the `fieldMapping` section maps
+provider-specific response fields to standard user identity fields (for example,
+GitHub returns `login` instead of the standard `name` field).
+
+When you omit `userInfo`, the embedded auth server runs in synthesis mode for
+this upstream: it derives a non-personally-identifying subject (with a `tk-`
+prefix) from the access token and leaves `name` and `email` empty. Use this
+configuration for OAuth 2.0 servers that don't expose a userinfo endpoint, such
+as MCP authorization servers that comply with the
+[MCP authorization specification](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization).
 
 :::
 

docs/toolhive/guides-k8s/deploy-operator.mdx

@@ -181,6 +181,40 @@ To see all available configuration options, run:
 helm show values oci://ghcr.io/stacklok/toolhive/toolhive-operator
 ```
 
+### Pull workload images from a private registry
+
+If your MCP server, proxy runner, vMCP, registry API, or embedding server images
+live in a private container registry, use `operator.defaultImagePullSecrets` to
+apply pull credentials to every workload the operator spawns:
+
+```yaml title="values.yaml"
+operator:
+  defaultImagePullSecrets:
+    - regcred
+    - name: backup-regcred
+```
+
+Each entry is the name of a Kubernetes Secret of type
+`kubernetes.io/dockerconfigjson` (or another image-pull-secret type) that must
+exist in the namespace where each workload is created. Plain string and object
+forms are equivalent.
+
+The secrets propagate to the pod spec and the operator-managed ServiceAccount of
+every workload-spawning controller: `MCPServer`, `MCPRemoteProxy`,
+`MCPRegistry`, `VirtualMCPServer`, and `EmbeddingServer`. Chart-level entries
+are appended to any per-CR `imagePullSecrets` already configured on the
+resource. Common per-CR fields are:
+
+- `spec.imagePullSecrets` on `MCPRegistry` and `VirtualMCPServer`
+- `spec.resourceOverrides.proxyDeployment.imagePullSecrets` on `MCPServer` and
+  `MCPRemoteProxy`
+
+Per-CR entries take precedence when a secret name appears in both places.
+
+The chart also exposes `operator.imagePullSecrets`, which controls only the
+operator's own pod. Use it when the operator image itself is in a private
+registry; use `defaultImagePullSecrets` for the workloads the operator manages.
+
 ## Operator deployment modes
 
 The ToolHive operator supports two distinct deployment modes to accommodate

docs/toolhive/reference/cli/thv.md

@@ -56,6 +56,7 @@ thv [flags]
 * [thv start](thv_start.md)	 - Start (resume) a tooling server
 * [thv status](thv_status.md)	 - Show detailed status of an MCP server
 * [thv stop](thv_stop.md)	 - Stop one or more MCP servers
+* [thv tui](thv_tui.md)	 - Open the interactive TUI dashboard (experimental)
 * [thv version](thv_version.md)	 - Show the version of ToolHive
 * [thv vmcp](thv_vmcp.md)	 - Run and manage a Virtual MCP Server locally
 

docs/toolhive/reference/cli/thv_tui.md

@@ -0,0 +1,62 @@
+---
+title: thv tui
+hide_title: true
+description: Reference for ToolHive CLI command `thv tui`
+last_update:
+  author: autogenerated
+slug: thv_tui
+mdx:
+  format: md
+---
+
+## thv tui
+
+Open the interactive TUI dashboard (experimental)
+
+### Synopsis
+
+Launch the interactive terminal dashboard for managing MCP servers.
+
+The dashboard shows a real-time list of servers with live log streaming,
+tool inspection, and registry browsing — all from a single terminal window.
+
+Key bindings:
+  ↑/↓/j/k   navigate servers or tools
+  tab        cycle panels: Logs → Info → Tools → Proxy Logs → Inspector
+  s          stop selected server
+  r          restart selected server
+  d d        delete selected server (press d twice)
+  /          filter server list, or search logs (on Logs/Proxy Logs panel)
+  n/N        next/previous search match
+  f          toggle log follow mode
+  ←/→        horizontal scroll in log panels
+  R          open registry browser
+  enter      open tool in inspector (from Tools panel)
+  space      toggle JSON node collapse (in inspector response)
+  c          copy response JSON to clipboard
+  y          copy curl command to clipboard
+  u          copy server URL to clipboard
+  i          show tool description (in inspector)
+  ?          show full help overlay
+  q/ctrl+c   quit
+
+```
+thv tui [flags]
+```
+
+### Options
+
+```
+  -h, --help   help for tui
+```
+
+### Options inherited from parent commands
+
+```
+      --debug   Enable debug mode
+```
+
+### SEE ALSO
+
+* [thv](thv.md)	 - ToolHive (thv) is a lightweight, secure, and fast manager for MCP servers
+

static/api-specs/crds/mcpexternalauthconfigs.schema.json

@@ -86,6 +86,10 @@
               "default": "sub",
               "description": "SessionNameClaim is the JWT claim to use for role session name\nDefaults to \"sub\" to use the subject claim",
               "type": "string"
+            },
+            "subjectProviderName": {
+              "description": "SubjectProviderName is the name of the upstream provider whose access token\nis used as the web identity token for STS AssumeRoleWithWebIdentity.\nThis field is used exclusively by VirtualMCPServer, where there is no\nupstream swap middleware to replace the bearer token before the strategy runs.\nWhen left empty and an embedded authorization server is configured on the\nVirtualMCPServer, the controller automatically populates this field with\nthe first configured upstream provider name. Set it explicitly to override\nthat default or to select a specific provider when multiple upstreams are\nconfigured.\nWhen no embedded auth server is present, the bearer token from the incoming\nrequest's Authorization header is used instead.",
+              "type": "string"
             }
           },
           "required": [
@@ -490,7 +494,7 @@
                         "type": "object"
                       },
                       "userInfo": {
-                        "description": "UserInfo contains configuration for fetching user information from the upstream provider.\nRequired for OAuth2 providers to resolve user identity.",
+                        "description": "UserInfo contains configuration for fetching user information from the upstream provider.\nWhen omitted, the embedded auth server runs in synthesis mode for this\nupstream: a non-PII subject derived from the access token, no Name/Email.\nUse this shape for upstreams with no userinfo surface (e.g., MCP\nauthorization servers per the MCP spec).",
                         "properties": {
                           "additionalHeaders": {
                             "additionalProperties": {
@@ -552,8 +556,7 @@
                     "required": [
                       "authorizationEndpoint",
                       "clientId",
-                      "tokenEndpoint",
-                      "userInfo"
+                      "tokenEndpoint"
                     ],
                     "type": "object"
                   },

static/api-specs/crds/mcpregistries.schema.json

@@ -24,6 +24,23 @@
           "description": "DisplayName is a human-readable name for the registry.",
           "type": "string"
         },
+        "imagePullSecrets": {
+          "description": "ImagePullSecrets allows specifying image pull secrets for the registry API workload.\nThese are applied to both the registry-api Deployment's PodSpec.ImagePullSecrets\nand to the operator-managed ServiceAccount the registry API runs as, so private\nimages are pullable through either path.\n\nUse this field for new manifests.\n\nImportant: this is the ONLY way to attach image-pull credentials to the\noperator-managed ServiceAccount. The legacy\nspec.podTemplateSpec.spec.imagePullSecrets path populates the Deployment's pod\nspec ONLY — it does NOT touch the ServiceAccount. On managed Kubernetes\nplatforms that rely on ServiceAccount-level credential injection (for example\nGKE Workload Identity, OpenShift's per-SA dockercfg secrets, EKS IRSA), using\nonly the legacy PodTemplateSpec path can fail to pull private images even when\nthe secret exists in the namespace. Always set spec.imagePullSecrets when\nSA-level credentials matter.\n\nPrecedence with PodTemplateSpec:\n  - This field is applied first as the controller-generated default.\n  - Values set under spec.podTemplateSpec.spec.imagePullSecrets are user overrides\n    and win on overlap. If the user supplies imagePullSecrets via PodTemplateSpec,\n    those replace the default list on the Deployment (the list is treated atomically).\n  - The ServiceAccount is always populated from this field — PodTemplateSpec does not\n    affect the ServiceAccount.\n\nAn omitted field and an explicitly empty list are equivalent: both leave the\nServiceAccount's existing ImagePullSecrets unchanged. This preserves\nplatform-managed pull secrets (for example OpenShift's per-SA dockercfg\nentries) when overlays or patches emit an empty list. Truly clearing the\nServiceAccount's pull secrets requires recreating the resource.",
+          "items": {
+            "description": "LocalObjectReference contains enough information to let you locate the\nreferenced object inside the same namespace.",
+            "properties": {
+              "name": {
+                "default": "",
+                "description": "Name of the referent.\nThis field is effectively required, but due to backwards compatibility is\nallowed to be empty. Instances of this type with an empty value here are\nalmost certainly wrong.\nMore info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names",
+                "type": "string"
+              }
+            },
+            "type": "object",
+            "x-kubernetes-map-type": "atomic"
+          },
+          "type": "array",
+          "x-kubernetes-list-type": "atomic"
+        },
         "pgpassSecretRef": {
           "description": "PGPassSecretRef references a Secret containing a pre-created pgpass file.\n\nWhy this is a dedicated field instead of a regular volume/volumeMount:\nPostgreSQL's libpq rejects pgpass files that aren't mode 0600. Kubernetes\nsecret volumes mount files as root-owned, and the registry-api container\nruns as non-root (UID 65532). A root-owned 0600 file is unreadable by\nUID 65532, and using fsGroup changes permissions to 0640 which libpq also\nrejects. The only solution is an init container that copies the file to an\nemptyDir as the app user and runs chmod 0600. This cannot be expressed\nthrough volumes/volumeMounts alone -- it requires an init container, two\nextra volumes (secret + emptyDir), a subPath mount, and an environment\nvariable, all wired together correctly.\n\nWhen specified, the operator generates all of that plumbing invisibly.\nThe user creates the Secret with pgpass-formatted content; the operator\nhandles only the Kubernetes permission mechanics.\n\nExample Secret:\n\n\tapiVersion: v1\n\tkind: Secret\n\tmetadata:\n\t  name: my-pgpass\n\tstringData:\n\t  .pgpass: |\n\t    postgres:5432:registry:db_app:mypassword\n\t    postgres:5432:registry:db_migrator:otherpassword\n\nThen reference it:\n\n\tpgpassSecretRef:\n\t  name: my-pgpass\n\t  key: .pgpass",
           "properties": {