n8n 2.38.7 - MCP Workers and Git CA Trust

n8n published [email protected] on 11 September 2026. The tag is a stable patch on the 2.38 line, with three core fixes. The change that alters queued execution is MCP toolkit dispatch. With EXECUTIONS_MODE=queue, an MCP Server Trigger runs the requested member of an attached MCP Client Tool. On the previous tag that call came back as did not return a valid Tool.

The full release notes and downloads are on the GitHub release page. The range against the previous tag is [email protected]…[email protected].

Queue mode runs jobs on workers, apart from the main process. On that path an MCP Server Trigger with an attached MCP Client Tool failed to select the toolkit member the caller named. The worker answered did not return a valid Tool, and the named member was never invoked.

Issue #38277, shipped as 1025dc7, fixes member selection in packages/cli/src/scaling/job-processor.ts. The same change closes the MCP connection after a successful call, after a missing tool, and after an invocation error. The next call opens a new connection.

The check described with the fix needs EXECUTIONS_MODE=queue, Redis, and a worker. The workflow is an MCP Server Trigger plus an MCP Client Tool pointed at a downstream MCP server that exposes at least two tools. Call the second tool over Streamable HTTP and compare the payload with a direct call to that server. After the fix the worker returns that tool’s output.

The tests named in the change live under packages/cli at src/scaling/__tests__/job-processor.service.test.ts. They cover tool selection, the missing tool error, and cleanup after success and after failure. Instances that keep the default execution mode never enter this path for the trigger. The defect shows up when execution is queued.

Chat Trigger and Form Trigger workflows set to n8n User Auth asked for OAuth consent again after a user had already approved. tryAutoApproveConsent ran once, on the first request to /oauth/authorize. At that moment the visitor was often still anonymous. Login happened later, on the way to the auth gated /oauth/consent page. No second reuse check ran. OAuthConsentController.getConsentDetails rendered the approve and deny picker on every load of that page, including when a UserConsent row for that user was already stored.

Issue #38249, commit 52c8a72, retries the reuse check inside OAuthConsentService.getConsentDetails once the user is authenticated. A match returns autoApproved together with redirectUrl. The editor follows redirectUrl at once. While the redirect is in flight the view stays blank. There is no picker and no “Access granted” flash.

The reproduction uses a production URL. Create the trigger, set Authentication to n8n User Auth, activate the workflow, and open the URL in a fresh session. Log in and approve once. Clear cookies and open the same URL again. Log in. The session should continue into the chat or the form. A user with no UserConsent row still gets the picker.

The thin part of the patch is the UI. Coverage on that change left seven lines open, in packages/frontend/editor-ui/src/app/stores/consent.store.ts, packages/frontend/editor-ui/src/app/views/OAuthConsentView.vue, and packages/cli/src/modules/oauth-server/oauth-consent.controller.ts. A front end that replaces OAuthConsentView.vue has to honor autoApproved and redirectUrl. Otherwise the picker stays on screen after login.

Source control starts Git through simple-git and passes an explicit environment. The child process receives only the variables the caller sets. GIT_SSL_CAINFO on the n8n process stopped at that boundary. A Git host signed by a private CA then failed with SSL certificate problem or unable to get local issuer certificate. The same git binary from a shell in the pod succeeded, because that shell inherited the variable. NODE_EXTRA_CA_CERTS updates Node trust. Git keeps a separate store, so the Node setting left this error in place.

Issue #38297, commit 3234078, changes buildHttpsGitConfig so it reads GIT_SSL_CAINFO and GIT_SSL_CAPATH from the n8n process and writes them into Git config as http.sslCAInfo and http.sslCAPath. Both Git services that open HTTPS remotes go through buildHttpsGitConfig. SSL_CERT_FILE and SSL_CERT_DIR stay unsupported. The variable to put on the deployment is GIT_SSL_CAINFO.

Two integration tests run a real Git binary against a local HTTPS server with a self signed certificate. Without the variable, Git returns the TLS error. With the variable, TLS succeeds. One test drives SourceControlGitService.setGitCommand and simple-git, which is the source control path. The other runs the config map from buildHttpsGitConfig under a replaced environment. On 2.38 the promotions module is absent, so the unit case sits in the git-connections utils test.

A public substitute, when no private CA is handy, is self-signed.badssl.com. Save its certificate and point GIT_SSL_CAINFO at the file:

openssl s_client -connect self-signed.badssl.com:443 -servername self-signed.badssl.com </dev/null 2>/dev/null | openssl x509 > /tmp/ca.pem

In Settings > Environments choose HTTPS and connect to https://self-signed.badssl.com/repo.git with any username and token. With this patch, Git clears TLS and reports that the repository was not found. That message means the certificate check passed. The host is not a Git server. Deployments that set only NODE_EXTRA_CA_CERTS still see the SSL certificate error until GIT_SSL_CAINFO is present on the n8n process.