n8n 2.41.4 Is Out: Stability Fixes Now, and the 2.42 Beta Shows n8n Is Rebuilding Around AI Agents

n8n shipped 2.41.4 on September 30, 2026 — the current stable release — and it is exactly what it looks like: four bug fixes, no new features. But the companion 2.42.0 beta is where the interesting work is happening: an Agent Builder overhaul, nested agent tools, deeper MCP integration, and tighter credential authorization. Taken together, the two releases tell one story — n8n is quietly rebuilding itself from a workflow tool into an agent orchestration platform, and the boring reliability fixes are a required part of that shift. Here’s what’s in each release, whether you should upgrade, and how to try the beta without putting production at risk.

A stable release is the version n8n officially recommends for production use. A beta is a preview line — usable for testing, not for workflows that pay your bills. n8n’s team ships betas so the community can exercise new features before they land in stable.

What’s actually in 2.41.4 (the stable)

Four fixes, each small on its own, each painful in production when it hits:

1. Execution API resilience. The API can now return an execution even when its stored trace context is incomplete. Before this, incomplete tracing data could block you from retrieving execution records at all — which is a miserable thing to discover at 2 a.m. during an incident.
2. Database health checks during event-loop lag. A database ping is now treated as successful when the reply arrives during event-loop lag, instead of falsely flagging a healthy database connection as failed. Self-hosted users who saw phantom “database unhealthy” warnings under load should see fewer of them.
3. Queue result isolation. Queue job results are now stored only for executions that were actually enqueued by the current process, so one process can’t persist results that belong to another. If you run queue mode with multiple workers, this is a real correctness fix, not cosmetics.
4. Cloud UBB Assistant credit visibility. On n8n Cloud, the Assistant banner now shows remaining credits, so you can watch consumption directly in the editor instead of discovering it in the billing tab.

None of this is dramatic — and that’s the point. These are the kinds of fixes that matter only once workflows run unattended at scale. Which is exactly where agents are about to take n8n.

The 2.42 beta: the bigger story

The 2.42.0 beta touches almost every layer involved in agent workflows. Here are the changes that matter, grouped by what they unlock.

AI agents get more flexible tooling

An AI Agent Tool — a wrapper that lets one agent use another agent’s tools — can now use its own tools when operating under a pre-v3 parent agent. That fix targets nested or hierarchical agent setups, where a supervisor agent delegates to sub-agents. Previously, tool calls in that configuration could silently fail or behave oddly; the beta closes that gap.

The Agent Builder gets the most visible attention: clearer sub-agent guidance, a more compact configuration header, better activity feedback, and improved capability chips. This is interface work, but it’s interface work with a thesis — n8n believes people will spend their time configuring relationships between agents in the editor, not just drawing node chains.

MCP leaves the experimental corner

MCP (Model Context Protocol, Anthropic’s open standard for exposing tools to AI models) is being promoted from an isolated capability into a first-class part of n8n:

• The MCP Registry in the AI Assistant moves beyond its previous feature-flagged state — it is now on by default.
• MCP workflow permissions get better handling, with clearer links from MCP workflow access errors to the settings that fix them.
• Outdated MCP notices are removed and MCP workflow headings improved.

Individually these look cosmetic. Together they signal that MCP is becoming how n8n expects agents to discover and use external tools — the wiring between your agent and the rest of the software world.

The Assistant becomes verifiable

n8n’s AI Assistant (the in-editor AI that helps build workflows) can now record live test runs as verification evidence. That’s a meaningful idea for agent work: when an agent’s behavior is non-deterministic, the artifact that proves it worked is the run itself, captured at test time. The beta also brings terminology and navigation updates, project icons in agent breadcrumbs, improved session handling — and one licensing note worth knowing: the AI Assistant project list is now gated behind the team-projects license.

Credentials get stricter — and that’s good

Two editor-side security improvements:

• Quick-connect OAuth credentials stay out of credential lists until the user actually authorizes them. Partially configured credentials no longer look available when they aren’t — a small change that prevents a whole class of “why does this auth fail” confusion.
• Azure OpenAI authentication now signs in as the application via Azure Entra, aligning with how enterprise Azure environments expect service identities to behave.

Core infrastructure keeps up

Beyond the agent features: better Redis reconnect behavior (restoring pub/sub subscriptions, detecting half-open subscriber connections), improved cleanup and retry for binary data directories and execution data, OpenTelemetry exports that survive restarts when Sentry is enabled, expression isolates released when webhook responses finish, and protection against duplicate daily instance reports. On the API side: workflow descriptions accepted at creation, extendsCredential support, and validation for OpenAPI path parameter names and token payloads.

Why the boring fixes are the agent story

Here’s my read on the pattern: traditional n8n workflows have predictable paths — trigger, process, call service, store result. Agent workflows don’t. The model picks tools, invokes sub-agents, talks to MCP servers, and credentials decide what it’s capable of accessing. The number of possible execution paths explodes, and every one of those paths depends on execution history being reliable, credentials being correct, queue behavior being predictable, and observability working.

So the unglamorous work in 2.41.4 (execution retrieval, database health, queue isolation) and 2.42 (Redis reconnects, OTel exports, execution cleanup) is not separate from the agent work. It’s the foundation the agent work stands on. A supervisor agent that can’t reliably retrieve its last execution is a liability, not a feature.

The honest trade-off: as agents make workflows less predictable, debugging gets harder for exactly the users the Agent Builder is trying to attract. Better guidance UI helps; it doesn’t remove the fundamental complexity. If you’re adopting agent nodes, invest in the boring stuff first — pinned versions, backups, and a staging instance.

Should you upgrade? (decision table)

Step 1 - Back up before upgrading

Export your workflows (⋮ menu → Export), back up your database (copy database.sqlite for the default, or snapshot Postgres), and confirm you have your N8N_ENCRYPTION_KEY saved somewhere safe. Without the exact same key after a restore, every stored credential becomes unreadable.

Step 2 - Upgrade the Docker install to 2.41.4

# 1. Pull the new stable image
docker compose pull n8n

# 2. Recreate the container with the new image
docker compose up -d

# 3. Watch the startup logs
docker compose logs -f n8n

Pin the version in your docker-compose.yml:

services:
  n8n:
    image: n8nio/n8n:2.41.4

You should see n8n ready on 0.0.0.0, port 5678 with no migration errors, and Settings → About in the editor should read 2.41.4.

Step 3 - Try the 2.42 beta safely (optional)

Run it as a separate container on a different port, never by upgrading your production install:

docker run -d --name n8n-beta -p 5679:5678 \
  -e N8N_ENCRYPTION_KEY=your-own-beta-key \
  docker.n8n.io/n8nio/n8n:2.42.1

Warning: beta builds can change behavior between releases and may not upgrade cleanly to the final stable. Use a throwaway encryption key, don’t import production credentials into it, and delete the container when you’re done evaluating.

Open http://your-host:5679 and poke at the Agent Builder, the MCP Registry in the AI Assistant, and the credential screens. The nested-tool fix under pre-v3 parent agents is worth testing if you run hierarchical agent setups.

What I didn’t verify (honest limits)

This breakdown is based on the release notes as reported and cross-checked against n8n’s GitHub release history; I did not diff every commit in the 2.42 beta line, and beta contents shift between builds — treat the beta feature list as “what’s in the pipeline” rather than a promise of the final 2.42.0. I also didn’t install the beta against a real production-like stack to measure the Redis or queue improvements, so the infrastructure claims rest on the release notes, not my own benchmarks. If you depend on any single fix (e.g. the queue-result isolation), check the official n8n release notes for the exact build that contains it before planning an upgrade.

FAQ

Is 2.41.4 a security release?

Not exactly — it’s a stability release from September 30, 2026. However, it became a security-fixed stable on October 1, 2026, when n8n’s bi-weekly security update shipped fixes in the 2.41.4 line. Upgrading to 2.41.4 covers both the stability fixes and the security patches.

Should I run the 2.42 beta in production?

No. Betas exist so the community can exercise new features before they land in stable. Run it on a throwaway instance if you want to evaluate the Agent Builder or MCP changes early.

Where are the official release notes?

On the n8n GitHub releases page and the n8n changelog. The beta lines are marked as pre-releases on GitHub.

What version should I pin in Docker Compose?

n8nio/n8n:2.41.4 for stable. Pin a fixed tag rather than latest so a restart never silently changes your version.

Key Takeaways

1. n8n 2.41.4 (Sep 30, 2026) is a four-fix stability release — execution API resilience, database health checks, queue result isolation, Cloud Assistant credit visibility. Upgrade production, pin the tag.
2. The 2.42 beta is the real story — Agent Builder upgrades, nested agent tools, MCP Registry out of feature-flag, quick-connect OAuth hygiene, and Azure Entra app sign-in.
3. The reliability fixes and the agent features are the same project — non-deterministic agent workflows need reliable execution history, auth, queue behavior, and observability more than deterministic ones do.
4. Try the beta on a throwaway instance only, with its own encryption key, and never import production credentials into it.

Next: once 2.42 hits stable, the Agent Builder’s sub-agent guidance is the feature to evaluate first — hierarchical agents are where the debugging gets hard, and that’s where the new UI earns its keep.

Images: Pexels