2026.10.02 Release Notes

Download installers, container images, Helm charts, and other release assets from the Istari Customer Portal.

Breaking Changes

Identity Service is on by default in the Istari-Platform chart

The Identity Service is the platform's single sign-in layer. It connects Istari to your organization's own identity provider, such as Zitadel, Keycloak, Microsoft Entra ID or PingFederate, and issues the access keys that scripts, the CLI and agents use. With the API Gateway in front of them, the registry and the Identity Service are reached through one API URL; the MCP service keeps its own hostname.

Breaking Change

The Istari-Platform chart's major version bump to 7.0.0 (from 6.x in the 2026.09 release) turns on five values that were off: identity.enabled, identity.clientIntegration.enabled, apiGateway.enabled, provisioner.enabled and identity.migrations.runAsJob. An upgrade with an unchanged values file deploys the Identity Service and the provisioner. The registry, frontend and MCP service then sign people in through the Identity Service, so until its database, its istari-identity secret and the Zitadel Configurator's zitadel-identity-service-env secret exist, nobody can sign in.

To keep the services authenticating against Zitadel, set both identity.enabled and identity.clientIntegration.enabled to false; setting only identity.enabled breaks sign-in. We also recommend provisioner.enabled: false, because with the Identity Service off its credentials go unused. See Turning the Identity Service off.

If you turn it off, step 1's API Gateway items still apply: its DNS, TLS and routing, and its image if you mirror images. The rest of step 1 and steps 2, 4 and 5 do not apply. Upgrade as in step 3.

You do not have to migrate identity providers to turn this on. Enabling the Identity Service does not change who signs your people in: on upgrade the chart imports your Zitadel organizations as tenants, with their people, and everyone keeps signing in through Zitadel exactly as before. Migrating to another provider is optional — the Identity Service also supports Keycloak, Microsoft Entra ID, and PingFederate (with preview support for more); see Identity Providers and Switching from Zitadel.

Enabling the Identity Service disables new PAT creation. The platform is moving away from personal access tokens (PATs); Access Keys are the new required default for programmatic access. Keys are safer than PATs: each key is a private key you download once, it expires (after one year at most, or sooner if you choose), it can be revoked on its own, and it works with any identity provider, where a PAT depends on Zitadel. Existing PATs continue to work, but once the Identity Service is enabled you can no longer create new ones. Update any client, CLI, or agent that authenticates with a PAT to use a key — see Move a Python script from a PAT to a key and PAT → Key Exchange.

Who is affected: every installation upgrading from the 2026.09 release, whatever its values file sets:

• The file does not mention identity. The upgrade turns the Identity Service on. Follow the steps below.
• The file sets only identity.enabled: false. identity.clientIntegration.enabled now defaults to true, which points the registry, frontend and MCP service at an Identity Service that is not deployed, so sign-in fails. Add identity.clientIntegration.enabled: false before you upgrade.
• The file sets both to false. The Identity Service stays off. We recommend also setting provisioner.enabled: false.
• The file already enables the Identity Service. It keeps running. Check the last two items of step 1, and that the Configurator is at 1.11.1 or later. If any service still uses a suffixed client ID such as frontend-c3d4, remove VITE_IDENTITY_ROUTER_CLIENT_ID and VITE_IDENTITY_SERVICE_CLIENT_ID from the istari-frontend secret and ISTARI_DIGITAL_IDENTITY_SERVICE_CLIENT_ID from the istari-mcp secret before you upgrade; the suffixed IDs override the fixed ones and can fail after an upgrade. See Upgrading from suffixed client IDs.

What to do

Add the Configurator's secret

If the Zitadel Configurator registered your Identity Service (the usual case), add zitadel-identity-service-env to identity.extraEnvSecrets. Without it, the Identity Service crash-loops on start and sign-in fails. An installation that registered the Identity Service in Zitadel by hand needs no entry; see the install page. An installation that switched to Keycloak or Microsoft Entra ID keeps the identity.extraEnvSecrets list its switch guide gave it, with the provider's secret listed last; do not replace it with the Zitadel secret alone.

1. Before you upgrade, put in place what the chart cannot supply. <customer_istari_fqdn> is the platform domain you set as common.mainFqdn. The API Gateway host is api.<customer_istari_fqdn>, or the host in common.apiFqdnOverride when set — the platform's new unified API URL, which the new DNS record points at.

   • A PostgreSQL database for the Identity Service, and the istari-identity secret. The database's role must be able to create a schema in it, and the secret holds ISTARI_DIGITAL_IDENTITY_SERVICE_DATABASE_URL; see Identity Service Secret. To check, run kubectl get secret istari-identity.
   • DNS, TLS and an Ingress or load-balancer rule routing the API Gateway host to the istari-api-gateway Service. The upgrade creates that Service, so on an installation that has not run the API Gateway before, the route can only be tested in step 4. If the API Gateway is already running, curl -fsS https://<API Gateway host>/registry/api/v2/health/readiness returns 200 now.
   • If you use the Zitadel Configurator (the usual case): version 1.11.1 or later, run again with configurator.identity_service_base_url set to https://<API Gateway host>/identity. The run creates or updates the zitadel-identity-service-env secret, which you add to identity.extraEnvSecrets as the warning above says. The base URL's default, https://identity.domain.com, makes Zitadel reject every sign-in callback. To check, run kubectl get secret zitadel-identity-service-env -o jsonpath='{.data.ISTARI_DIGITAL_IDENTITY_SERVICE_BASE_URL}' | base64 -d. It must print https://<API Gateway host>/identity. An installation whose Configurator ran with the default prints https://identity.domain.com and must run it again.
   • If you registered the Identity Service in Zitadel by hand instead, skip the Configurator item above. You have no zitadel-identity-service-env secret and need no identity.extraEnvSecrets entry; your registration's values stay in istari-identity. An installation that switched to Keycloak or Microsoft Entra ID keeps the identity.extraEnvSecrets list its switch guide gave it. If you registered by hand, also add the Zitadel management key, ISTARI_DIGITAL_IDENTITY_SERVICE_ZITADEL_MANAGER_KEY, to istari-identity; Manual registration creates it. Or set identity.idpMigration.enabled: false, which skips creating tenants from your Zitadel organizations, so you create them by hand.
   • If you supply the registry's identity credential yourself, both halves of its key pair under the current names, or neither. The private half is ISTARI_DIGITAL_IDENTITY_SERVICE_CLIENT_CREDENTIALS in the registry's secret, istari-fileservice; the public half is ISTARI_DIGITAL_IDENTITY_SERVICE_REGISTRY_PUBLIC_KEY_B64 in istari-identity. The legacy name FILE_SERVICE_IDENTITY_ROUTER_SECRET alone no longer works once the provisioner runs, and neither does supplying only one half.

   Then check that:

   • The Zitadel management key's service user is a member of every Zitadel organization that should become a tenant. If the import misses one, add the service user to it and upgrade again.
   • If you mirror images, you have also mirrored identity-service, provisioner and istaridigital.com/caddy-fips, the API Gateway's image.
   • The cluster has room for the Identity Service (requests of 1 CPU and 2 GiB), two API Gateway replicas, and the schema-migration Job (requests of 500m CPU and 1 GiB) while it runs.

2. If you use Secure Connections, configure the Secure Connection Service to authenticate through the Identity Service in the same upgrade. With the Identity Service on, the registry no longer accepts the service's Zitadel token. Follow If You Use the Secure Connection Service. The usernameEnv setting there binds the service's Identity Service agent to its existing Zitadel machine user, so the registry keeps the same user record and files the service has received keep their owner. Keep usernameEnv pointing at the Configurator's ISTARI_DIGITAL_IDENTITY_SERVICE_SCS_AGENT_USERNAME, which holds the service's existing Zitadel user ID; any other value binds the agent to a different registry user.

3. Upgrade. Plain --reuse-values keeps the 6.x defaults, so the Identity Service stays off. Use Helm 3.14 or later:

   helm upgrade --reset-then-reuse-values -f istari-values.yaml istari istari-platform-7.2.0.tgz

   The registry, frontend and MCP service roll during the upgrade. If you kept the Identity Service on, wait for it to roll out before you verify:

   kubectl rollout status deployment/istari-identity

   If you changed the Secure Connection Service's settings in step 2, restart it. Its settings are in its secret, and nothing rolls it when they change:

   kubectl rollout restart deployment/istari-secure-connection

4. Verify. Follow Verify the Identity Service: the Identity Service's readiness and JWKS endpoints return 200 through the API Gateway, a person can sign in, and the tenant list shows one tenant for each Zitadel organization you expect.

5. Grant the platform administrator role. The installation needs at least one platform administrator before anyone can create tenants, and the chart grants the role to no one. ensure-platform-admins cannot grant the role to a person the Zitadel import created until they have signed in once, so run it after step 4's sign-in. Follow Creating Platform Administrators.

See the Istari Platform Installation guide for the full install steps.

Secure connections belong to a tenant

Breaking Change

Every secure connection now belongs to one tenant, and the upgrade places existing connections in the default tenant. Connections that serve people in another tenant must be recreated there.

• Administrators see only their own tenant's connections; a connection's members must belong to its tenant.
• Existing members from other tenants keep their access until removed.
• Follow the Secure Connection Tenancy Migration Guide.

Legacy registry-to-registry remote sync is removed

Breaking Change

Remote sharing v1 (the /api/v2/upstream-remotes API, its registry settings and Python client methods) is removed. Secure Connections replace it.

• Files received through a v1 remote stay readable and keep their connection badge, tenant and access, but no longer receive updates.
• Remove any FILE_SERVICE_UPSTREAM_REMOTES__* settings and replace scripts that called the upstream-remotes API.

AI tool names carry the MCP server prefix

Breaking Change

The tool names the model sees, and the tool_call events on POST /api/v3/ai/chat/stream, are now prefixed with the MCP server name: istari_search instead of search. Integrations that match on exact tool names must update.

Single-model AI variables are no longer read

Breaking Change

FILE_SERVICE_AI__MODEL, FILE_SERVICE_AI__API_KEY, FILE_SERVICE_AI__BASE_URL, FILE_SERVICE_AI__API_VERSION, FILE_SERVICE_AI__EXTRA_PARAMS and FILE_SERVICE_AI__PROVIDER are ignored from the first start of this release. A deployment whose only model came from them has no model after the upgrade, and chat reports that AI is not configured, until a connection exists. Follow In-product AI: model configuration moves to connections before you upgrade; it also covers the sealing secret and the September host-slot variables, both of which lose data if handled in the wrong order.

Blocking AI chat endpoint removed

Breaking Change

POST /api/v3/ai/chat is removed; POST /api/v3/ai/chat/stream is the only chat path. Istari Python Client 13.3 and later no longer has the chat and selectable-models calls or the ChatRequest, ChatResponse and UserSelectableModelsResponse types. Scripts that called them must move to the streaming endpoint. The registry still serves GET /api/v3/ai/models for the web app.

Migration Notes

In-product AI: model configuration moves to connections

Model selection now lives in the AI connections catalog, managed from Admin → LLMs and AI Instructions → LLMs or declared in the environment. The six single-model variables listed under Breaking Changes are no longer read; the operational variables (FILE_SERVICE_AI__MCP_SERVER_URL, FILE_SERVICE_AI__REQUEST_TIMEOUT and the rest) are unchanged. Before upgrading a deployment that relied on them:

1. Set FILE_SERVICE_REMOTE_MASTER_SECRET to its final value before the upgrade (at least 32 characters) and never change it afterwards. Keys pasted in the web app and credentials migrated from the September host slots are sealed under it; changing it later makes them undecryptable and chat on those connections fails with a 503. If the variable is already set for the Secure Connection Service, keep its value.

2. Leave the September host-slot variables (FILE_SERVICE_AI_NN_HOST / _AUTHN) in place through the upgrade. The upgrade migration reads each _AUTHN value once and turns every endpoint created on the Endpoints and Models page into a connection. Remove the variables after the connections show on the LLMs page; nothing reads them once the migration has run.

3. Decide who owns the configuration. An organization administrator can add a connection and pick models from Admin → LLMs and AI Instructions → LLMs after the upgrade, with no environment change.

4. For infrastructure-managed deployments, declare the connection in the environment instead: one JSON object in FILE_SERVICE_AI__CONNECTIONS, or per-field variables:

   FILE_SERVICE_AI__CONNECTIONS__OPENAI__PROVIDER=openai
   FILE_SERVICE_AI__CONNECTIONS__OPENAI__AUTH_MODE=key
   FILE_SERVICE_AI__CONNECTIONS__OPENAI__CREDENTIAL_ENV=OPENAI_API_KEY_PROD
   FILE_SERVICE_AI__CONNECTIONS__OPENAI__MODELS__GPT4O__MODEL_ID=gpt-4o

   AUTH_MODE is required for a keyed provider: it defaults to iam, which the registry rejects for a provider without a cloud identity and skips the connection. Environment-declared connections appear in the admin page as read-only.

   CREDENTIAL_ENV names the variable that holds the key; it does not hold the key itself. Put the key in that variable (OPENAI_API_KEY_PROD above) in the registry service secret, for example by moving the value of FILE_SERVICE_AI__API_KEY there. A connection whose variable is unset shows on the LLMs page as API key missing and chat skips it.

5. Keep FILE_SERVICE_AI__MCP_SERVER_URL set; it is what enables the assistant's tool use.

Provider prerequisites (Bedrock IAM policies, Azure AI Foundry roles, credentials by provider, egress and private-CA requirements) and the frontend settings are in AI Chat Setup.

Assets

Docker Images

• Registry Service: istaridigital.jfrog.io/customer-docker/registry-service:12.0.1
• Secure Connection Service: istaridigital.jfrog.io/customer-docker/secure-connection-service:12.0.1
• Frontend Service: istaridigital.jfrog.io/customer-docker/frontend-service:9.0.2
• MCP Service: istaridigital.jfrog.io/customer-docker/mcp-service:0.10.0
• Identity Service: istaridigital.jfrog.io/customer-docker/identity-service:2.4.0
• Provisioner: istaridigital.jfrog.io/customer-docker/provisioner:0.5.1
• SpiceDB: istaridigital.jfrog.io/customer-docker/istaridigital.com/spicedb-fips:v1.56.2
• SpiceDB Operator: istaridigital.jfrog.io/customer-docker/istaridigital.com/spicedb-operator-fips:v1.27.0
• Zitadel (main image): istaridigital.jfrog.io/customer-docker/istaridigital.com/zitadel:v3.4.15
• Zitadel (setup job): istaridigital.jfrog.io/customer-docker/istaridigital.com/kubectl-iamguarded-fips:1.35.9

Note: The SpiceDB, SpiceDB Operator, and Zitadel images listed above use Chainguard hardened images. Chainguard images are minimal, security-hardened container images with significantly reduced CVE exposure.

• NATS images (bundled with the NATS subchart in the Istari-Platform Chart; tags pinned by the chart):

  • NATS Server: istaridigital.jfrog.io/customer-docker/istaridigital.com/nats-fips:2.15.1
  • NATS Config Reloader: istaridigital.jfrog.io/customer-docker/istaridigital.com/nats-server-config-reloader-fips:0.24.0
  • NATS Prometheus Exporter: istaridigital.jfrog.io/customer-docker/istaridigital.com/prometheus-nats-exporter-fips:0.20.2
  • NATS Box: istaridigital.jfrog.io/customer-docker/istaridigital.com/nats-box-fips:0.20.0

• Other bundled images (pinned by the Istari-Platform Chart):

  • Jaeger: istaridigital.jfrog.io/customer-docker/istaridigital.com/jaeger-fips:2.22.0
  • Caddy (API Gateway): istaridigital.jfrog.io/customer-docker/istaridigital.com/caddy-fips:2.11.7

Helm Charts

• SpiceDB Operator: helm pull --repo https://bushelpowered.github.io/spicedb-operator-chart spicedb-operator --version 2.6.0
• Zitadel: helm pull --repo https://charts.zitadel.com zitadel --version 8.13.4
• Istari-Platform Chart: helm pull oci://istaridigital.jfrog.io/customer-charts/istari-platform --version 7.2.0 --username ${ISTARI_ARTIFACTORY_USERNAME} --password ${ISTARI_ARTIFACTORY_PASSWORD}
• Zitadel Configurator: helm pull oci://istaridigital.jfrog.io/customer-charts/istari-zitadel-configurator --version 1.11.4 --username ${ISTARI_ARTIFACTORY_USERNAME} --password ${ISTARI_ARTIFACTORY_PASSWORD}

SDK Clients

• Python 14.0.0

Agent

• v11.12.0

CLI

• v0.21.23

Integrations

Updates for the October 2026 Release

Module Name	Version
C-Infinity AutoAssembler Module	1.0.6
Dassault Systèmes 3DExperience CATIA (v6)	1.5.0
Dassault Systèmes 3DExperience ENOVIA	1.7.3
Dassault Systèmes Cameo Enterprise Architect	4.6.1
Dassault Systèmes CATIA V5	2.5.9
Google Workspace	1.5.1
Hexagon Nastran Extract	2.4.11
IBM Engineering Lifecycle Management (ELM)	1.0.1
IBM Rational DOORS Module	2.0.0
Jira & Confluence Data Extraction Module	1.2.6
Luminary Cloud CFD	1.1.9
Microsoft Office 365	1.6.9
Microsoft Office Excel	2.4.4
Microsoft Office PowerPoint	1.1.3
Microsoft Office Word	2.3.15
nTop	0.4.14
Open CAD	1.1.13
Open PDF	1.8.3
Open Spreadsheet	2.3.19
PTC Creo Parametric	3.3.9
Siemens NX	1.5.7
Zoo.dev	1.0.10

All Compatible Modules

Click to expand full module compatibility list for the October 2026 release of the Istari Platform

Module	Version
ANSYS HFSS	1.1.2
ANSYS STK	1.2.0
C-Infinity AutoAssembler Module	1.0.6
Dassault Systèmes 3DExperience CATIA (v6)	1.5.0
Dassault Systèmes 3DExperience ENOVIA	1.7.3
Dassault Systèmes Cameo Enterprise Architect	4.6.1
Dassault Systèmes CATIA V5	2.5.9
Google Slides	0.2.3
Google Workspace	1.5.1
Hexagon MSC Nastran	2.4.7
Hexagon Nastran Extract	2.4.11
IBM Engineering Lifecycle Management (ELM)	1.0.1
IBM Rational DOORS Module	2.0.0
Jira & Confluence Data Extraction Module	1.2.6
Luminary Cloud CFD	1.1.9
MathWorks MATLAB (Base)	2.3.8
MathWorks MATLAB Simulink	1.3.11
Microsoft Office 365	1.6.9
Microsoft Office Excel	2.4.4
Microsoft Office PowerPoint	1.1.3
Microsoft Office Word	2.3.15
nTop	0.4.14
Open CAD	1.1.13
Open PDF	1.8.3
Open Spreadsheet	2.3.19
Open SysML	1.0.11
Open Text	1.0.11
PTC Creo Parametric	3.3.9
Siemens NX	1.5.7
SOLIDWORKS	1.2.3
SysGit SysML v2 Tools	1.0.3
Zoo.dev	1.0.10

---

Change Log

Istari Platform

New Features

• Istari AI is generally available. The AI assistant opens as a panel on any system, branch, directory or resource page and already knows what you are looking at. It works through the platform's own API with your permissions, so it can see and do exactly what you can, nothing more.

  • Ask about a system. "Summarize this system" or "what changed on this branch" needs no setup. The assistant reads the system's files and the artifacts modules extracted from them, so questions about requirements, geometry metadata or report contents are answered from the right place.
  • Build a system. Ask the assistant to create a system, draft files into it, and run extraction and other jobs, including jobs that need a linked Microsoft 365, Google Drive or DOORS Next account. Drafted files and chat transcripts save to the system's current branch.
  • Share it. Ask the assistant to share a system or file, or share the chat transcript straight from the chat window. Sharing, control-tag, administrative and information-security actions pause for your approval before they run.

  Administrators connect providers and choose models (AWS Bedrock, Azure AI Foundry, Google Vertex AI, OpenAI, Anthropic, or an OpenAI-compatible endpoint) under Admin → LLMs and AI Instructions → LLMs. Each user turns the assistant on under Application → Experimental Features unless the deployment turns it on by default. To deploy it, follow AI Chat Setup; to use it, see Istari AI Chat.

• More identity providers: Identity Service 2.3.1 or later supports PingFederate, alongside Zitadel, Keycloak, and Microsoft Entra ID, with Okta in preview. Identity Service 2.4.0 or later adds Google and Lastwall in preview.

• Agent Management shows each agent's last successful job: the agent list and the get-agent response now include last_successful_job_at, and Agent Management shows when each agent last completed a job. It is empty for an agent that has never completed one. The upgrade adds a database index on job status to keep the list fast on large installations.

• Job details show inputs to anyone who can see them: the Inputs section of a job used to appear only for the person who started the job. It now follows each viewer's own access, so a teammate with access to an input resource sees it, with its link, whoever started the job. An input a viewer is not allowed to see is left out entirely.

• Secure connections are tenant-scoped: every connection belongs to one tenant; see Secure connections belong to a tenant under Breaking Changes.

• Content search. Search now finds matches inside the text of files, not only in names and descriptions. Text, PDF and DOCX contents are indexed in the background, and a result that matched on content shows a short excerpt with the matched words in bold, so it is clear why it appears (on the API, the new content_snippet field on search results, with the matched terms delimited by U+0002 and U+0003). Matching is keyword based, with English stemming and accent folding. Off by default: set FILE_SERVICE_CONTENT_INDEX_ENABLED=true to run the indexer and FILE_SERVICE_CONTENT_SEARCH_ENABLED=true to include file contents in search results. A newly uploaded file becomes searchable within about a minute: text is extracted every 15 seconds (FILE_SERVICE_CONTENT_INDEX_INTERVAL_SECONDS) and the search index refreshes every 30 seconds (FILE_SERVICE_SEARCH_INDEX_REFRESH_INTERVAL_SECONDS).

• Search within a system (Preview). GET /api/v3/systems/{system_id}/search searches the resources tracked in a branch's current snapshot by name, description and, when content search is on, file text, with optional branch selection, cursor pagination, and a count of resources whose content could not be searched.

• Job outputs carry their output name: every job-output upload now sends the name of the output it fulfils, which is how the registry applies the control tags chosen for that output.

• Open CAD 1.1.13 — Security patch: the bundled cad-geometry-toolkit moves to 1.0.8 on every platform, which brings pillow 13.0.0 (17 image-decoding CVEs, including CVE-2026-112403 and CVE-2026-96639) and certifi 2026.10.23, which no longer trusts the compromised emSign ECC Root CA - G3. Rendered views are back on Ubuntu 22.04: the install script now bundles the toolkit's rhel8 build (glibc 2.28) instead of the ubuntu build, which needs glibc 2.38 and could not start there, so extractions silently left out the views output. Headless view rendering also works on Linux hosts whose graphics libraries need a newer libstdc++ than the toolkit bundles, and every install and build script now runs the toolkit once and fails if it cannot start.

• IBM Engineering Lifecycle Management (ELM) 1.0.1 — New module. The DOORS Next, EWM, ETM and Rhapsody Model Manager functions move here from IBM Rational DOORS 1.4.x with the same function keys, metadata files and output names, so existing Resources keep working; the behaviour differences are listed in the module's changelog. It calls only the Jazz web APIs, so it runs on Windows, Ubuntu 22.04 and RHEL 8 agents without a DOORS desktop client. 1.0.1 patches pillow and certifi.

• IBM Rational DOORS Module 2.0.0 — DOORS Classic only. The DOORS Next, EWM, ETM and Rhapsody Model Manager functions are removed; install IBM ELM alongside it to keep extracting from those products. In the agent configuration the ibm_elm_*, ibm_ewm_*, ibm_etm_* and ibm_rmm_* keys move from the @istari:ibm_doors block to a new @istari:ibm_elm block; ibm_doors_log_level, ibm_doors_log_file_path and ibm_doors_fail_job_on_extraction_error are copied into it under ibm_elm_ names and stay in the DOORS block, which still reads them.

Performance, Stability, and Bug Fixes

• AI chat recovers from provider and tool hiccups. Transient model errors (429, 5xx, timeouts, connection resets) are retried before anything is sent to the user. Each model call is bounded by a request timeout, 120 seconds by default (FILE_SERVICE_AI__REQUEST_TIMEOUT, or request_timeout in a model's extra parameters), so a stalled completion fails visibly instead of hanging the turn. The connection to the MCP server is retried on a transient 503 and closed cleanly at the end of every turn.
• Fewer, cheaper tool calls. The assistant is steered to plan a data pull up front and fetch it in as few programs as possible, earlier tool calls and their results are carried into later turns of the same conversation (measured at about a third fewer tool calls), and large tool results from earlier steps are trimmed to keep token use bounded. With extended thinking on, Claude models keep their signed reasoning across a tool call instead of re-deriving it at every step (return_thinking_blocks, per model, off by default).
• A slow AI tool call no longer poisons the next ones. In the MCP service, a program that exceeds its time limit keeps its execution slot until it actually exits, queue wait counts against the budget, and a timed-out program that writes is never re-run. Previously a single long read could leave the sandbox reporting "failed and returned no result" for the calls that followed.
• Chat turns are traceable end to end. Completion and error events on the chat stream carry a correlation ID, and each turn emits spans covering model resolution, tool calls, retries and the outcome.
• Choose Agent no longer hides capable agents: the list in the Create Job panel asked only for agents on the newest module version, and stopped at one page, so a single up-to-date agent hid every other agent that could run the job. It now lists every agent that has the module, at any version and across all pages, with agents on the newest version first and the outdated-version tag now shown on the rest.
• Images updated for the eMudhra vulnerability: all images in this release have been updated to address the eMudhra vulnerability. None of the images use PHP, so they are not affected by recent PHP vulnerabilities.
• Zitadel Configurator works without an internet connection: the Zitadel Configurator no longer requires an internet connection to run.
• Choose Agent says why an agent cannot be used: an agent whose operating system is not declared by the module version it holds is greyed out and tagged OS not supported, with a tooltip naming the operating system and the version, instead of looking selectable and then failing at submission.
• Bedrock Claude models newer than the bundled model map now work. They are routed through the Converse API without a temperature parameter, which removes the HTTP 400 errors and truncated output that previously needed a manual workaround; Claude Opus 5 on Bedrock no longer fails with a generic error.
• Reasoning models no longer produce empty or invented answers. The final answer is extracted correctly from structured thinking-plus-text output, a turn that hits its tool-call budget returns a summary of what was found instead of silence, and a blank assistant turn is padded so providers do not merge the surrounding user messages.
• An expired session token no longer breaks a chat. The web app refreshes the access token before opening a chat stream.
• Large branches no longer break the assistant's listing. The SDK looks resources up in chunks, so a branch with thousands of files no longer fails with a request-too-large error.
• Related models and artifacts come back from the SDK again. get_related_resources dropped them in python-client 13.3.0 through 13.3.3; 13.3.4 returns them.
• Approval prompts no longer look like a hang. A gated tool call delivers its approval prompt in the chat instead of failing silently or being retried indefinitely, and the MCP handshake no longer rejects the turn.
• The Artifacts panel keeps its contents while the assistant's provisional lookups miss.
• The agent stops trusting a compromised root certificate: eight intermediate certificate authorities that chain to emSign ECC Root CA - G3 had their private keys compromised. By default the agent trusts the bundled certifi, which is updated to 2026.10.19 and no longer contains that root, and the Docker images pick up the fixed certifi as well. The agent's gRPC connections (OTLP export) now start from SSL_CERT_FILE when it is set, and from certifi otherwise; a customer who sets GRPC_DEFAULT_SSL_ROOTS_FILE_PATH keeps that value, so check that the bundle it points to does not contain the compromised root. gRPC does not read ISTARI_CLIENT_CA_BUNDLE or REQUESTS_CA_BUNDLE, which apply to the agent's HTTPS calls only. Updating certifi does not change a CA bundle you manage yourself: if you point the agent at one of your own bundles, remove the compromised root from it. Windows Update does not cover this either, because it reaches only the Windows certificate store, not the agent's bundles.
• Two module folders that declare the same module key no longer load an arbitrary one: when more than one folder under istari_modules declares the same module key, the agent used whichever came last in directory order, which depends on the file system and could differ between hosts. It now logs one error naming the key and each folder with its version, and loads none of them. The module reads as not installed, so this agent does not claim its jobs and they stay available to other agents. Other modules load normally.
• Agent logging survives a log rollover on Windows: the agent held istari_agent.log open through two handlers, so the first rollover at 10 MB failed on Windows and, because the agent runs without a console, every later log line was silently dropped while the agent kept running. The log file now has a single handler, and a rollover that cannot complete no longer discards the record that triggered it or deletes older log files.
• Modules start from a read-only folder: on a per-machine Windows install the agent cannot write to a module's folder under %ProgramFiles%, so modules that open a log at a relative path (Python, Java and C# modules) failed with PermissionError. The agent now starts such a module with %ProgramData%\IstariDigital\istari_agent\module_logs\<module> as its working directory. Where the module folder is writable, nothing changes. Modules whose launcher starts a child Java process, such as Cameo and Creo, are not covered by this change.
• Inputs with compound extensions keep their name: a revision stored with a compound extension, such as a Creo foo.prt.1, was staged as foo.prt.prt.1, and the job failed to open the model. The agent now stages it as foo.prt.1.
• Re-running a job creates a new revision of its earlier outputs: outputs became new revisions of the artifacts an earlier run produced only once the input itself had been revised, so re-running a job on a model with a single revision, such as a connected-file model, created new artifacts for every output on every run. Outputs now version against the input's current revision, including when the input is an artifact in a chain of jobs. Only artifacts stored directly under the job's input are reused; artifacts of another model, or archived ones, are not.
• Dependency security patches: pillow is upgraded to 13.0.0 and dnspython to 2.9.0.
• The CLI stops trusting a compromised root certificate: the bundled certifi is updated to 2026.10.19, which removes emSign ECC Root CA - G3 and the intermediates that chain to it. By default, every HTTPS call the CLI makes, including those of the Istari Digital SDK, trusts that bundle, so this needs the new CLI rather than a Windows update. If you set ISTARI_CLIENT_CA_BUNDLE, REQUESTS_CA_BUNDLE or SSL_CERT_FILE to a CA bundle of your own, the CLI uses that bundle instead and the upgrade does not change it: remove the compromised root from it.