Skip to content
Writing
By MD Jehad H.··4 min read·Operator playbook

HubSpot chatflow custom code goes read-only today

Drafted through my n8n + AI pipeline, edited by me.

Node.js runtime lockouts hit HubSpot chatflows today. Any custom code snippet powering a chatbot that still runs on Node 18.x or 20.x goes read only as of August 31, 2026, and stays that way until someone switches it to Node 24.x.

What HubSpot changed today

HubSpot flagged this months ago in its developer changelog. Node 18.x and 20.x reached end of life and stopped receiving security patches. Today is the actual cutover. Any chatflow bot with a custom code snippet still pointed at one of those runtimes loses its edit button. The bot keeps running as configured, but nobody can touch the logic, the copy, or the routing rules inside that snippet until the runtime gets switched to Node 24.x, the current long term support release.

Why this matters for a small business

Most owners never reopen the chatflow builder after the initial setup. A freelancer or an agency wired up a lead qualification bot two or three years ago, it has been quietly routing website visitors ever since, and nobody has looked at the code snippet behind it since launch. That is exactly the setup this deadline catches. The bot will not break today. It will just freeze in whatever state it is in, right as the next product update or seasonal promotion needs a tweak to that same logic.

  1. 1

    Open Conversations, then Chatflows

    List every active bot, including ones built by a past contractor or agency you no longer work with.

  2. 2

    Check each custom code action

    Open the code editor for any bot step that runs custom code and note the runtime version shown.

  3. 3

    Switch Node 18.x or 20.x to Node 24.x

    Use the in-place runtime switch. It keeps the code, environment variables, and configuration intact, no rebuild needed.

  4. 4

    Test the full conversation path

    Run the bot end to end after the switch, not just the snippet in isolation, since branching logic can behave differently on a newer runtime.

Where chatflow custom code hides in a service business

The snippets that get missed are rarely the obvious ones. Think of the bot that checks a zip code against a service area before offering a booking link, the one that looks up a customer's plan tier in a connected CRM property before answering a pricing question, or the one that routes after hours messages differently depending on the day of the week. Those typically run through a custom code action, and they are usually the part of the automation nobody has opened since the person who built it moved on.

Comparison of a HubSpot chatflow custom code snippet left on Node 18.x or 20.x versus switched to Node 24.x after the August 31, 2026 deadline

  • Snippet locks to read only starting today
  • Routing logic, copy, and rules can't be edited
  • Bot keeps executing whatever was last saved
  • Still built on an unpatched, unsupported runtime
Left on Node 18.x or 20.x, a chatflow snippet freezes today. Switching to Node 24.x keeps it editable with no rebuild.

No rebuild needed

The runtime switch is in place now. You do not need to delete and rebuild the snippet, HubSpot preserves the code, environment variables, and configuration through the change.

This kind of deadline is easy to miss because it never announces itself as an emergency, it just sits in a changelog for months before the date lands. If you want a second set of eyes on which of your bots, forms, or connected workflows have a quiet dependency like this one sitting inside them, that is the kind of audit worth doing before the next platform update catches you the same way.

Building something this should run inside?

Book a systems call

Keep reading