The Claude Code Changelog
All Episodes
Claude Code 2.1.310: Replace Polling with Monitor

Claude Code 2.1.310: Replace Polling with Monitor

0:00|0:00

Claude Code 2.1.310 enables the Monitor tool on Amazon Bedrock, Google Vertex, and Microsoft Foundry—even with telemetry or nonessential traffic disabled. Learn how to replace sleep-and-check loops with event-driven monitoring, configure permissions, and avoid leaving background monitors running.

The episode also covers gateway retry behavior, a compaction fix, clearer symlink permission prompts, Linux sandbox guidance, and custom Enterprise roles for cloud sessions and Remote Control.


Chapter 1

Monitor Replaces Sleep Loops in 2.1.310

Lachlan Reed

Right, so picture Claude Code running a build, and instead of waiting for it, it just types sleep sixty, checks, types sleep sixty again. That's a bit like standing at the oven door asking the roast if it's done yet. This is The Claude Code Changelog, brought to you by Jellypod AI, and today it's version 2.1.310, released October 23rd, and the fix for exactly that habit.

James Turner

Here's what changed. The Monitor tool, and plugin monitors, are now enabled on Amazon Bedrock, Google Vertex, and Microsoft Foundry. They also now work when telemetry or nonessential traffic is disabled, so that's DISABLE_TELEMETRY set to 1, or CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC set to 1. Per the changelog, long foreground sleeps are now blocked in those same environments too. So Claude can't fall back on a long sleep in Bash there anymore.

Lachlan Reed

And that lines up with last episode's story, James. In 2.1.309 we talked about features that simply weren't there on Bedrock and Vertex, ultrareview being the example. Enterprise setups kept getting the leftovers. This one closes a real gap.

James Turner

It does. Monitor has been around since 2.1.98, but on third party clouds it was restricted, and it broke if those privacy flags were set. So in exactly the locked down environments, Claude fell back to crude loops to watch dev servers, builds, test runners, and log files. Two costs there. Every check is another Bash call, so you burn context on the same question over and over. And a long foreground sleep freezes your turn while nothing useful happens.

Lachlan Reed

So what does Monitor actually do instead? According to the tools reference, it runs a command in the background and feeds each output line back to Claude, so it can react to log entries, file changes, or polled status in the middle of the conversation. It can also open a WebSocket and treat each incoming message as an event. The point is that it's interrupt driven. Claude only wakes up, and only spends tokens, when something actually shows up.

James Turner

Using it is mostly a matter of how you phrase the prompt. Describe the event, not the wait. For example: run npm run dev and monitor localhost:3000 until the server is ready, then run the smoke tests. Or: tail server.log in the background and tell me the moment a 5xx error shows up. Or: run the test suite in the background and alert me if anything fails. Each of those names a condition, and that's what Monitor is built around.

Lachlan Reed

If you use the self pacing slash loop command, that one leans on the Monitor tool to wait for status changes without polling, so it benefits from this as well. Now, permissions. Monitor is marked as requiring permission in manual mode, so the first time Claude spawns a watcher, you'll get a prompt showing the exact command it's about to run in the background. In auto mode, the classifier makes that call. And for teams, you can allow or deny it in your settings. Put the tool name Monitor in permissions.allow or permissions.deny in .claude/settings.json. The docs also list Bash command patterns, like Bash with npm run star, as applying to both Bash and Monitor.

James Turner

Now the caveats. First, anything you wrote that says sleep thirty seconds and check again is going to hit a wall in these environments. That includes custom skills and saved prompts. Rewrite them to name the event: watch the build log until it completes. Second, a monitor is a real background process. A forgotten one keeps consuming memory or CPU. Use slash tasks to see what's running, and the TaskStop tool, or slash tasks itself, to end it. Third, those permission prompts will show up in manual mode, so expect a few more approvals the first time through.

Lachlan Reed

Quick round of smaller things in 2.1.310. If you're behind a gateway, like LiteLLM or a corporate proxy, that rejects the effort beta value or mid conversation system messages, Claude Code now retries without them, instead of just failing. There's a compaction fix too. After a Prompt is too long error, compaction used to keep too much dense text, think base64 or SVG, so the very next request could fail again. That's fixed.

James Turner

Security wise, file read permission prompts now show where a symbolic link leads, so you can see the real target before you approve. On Linux, slash sandbox and the startup warning now name Ubuntu's AppArmor restriction on user namespaces when it stops bubblewrap from starting the sandbox, and they tell you how to lift it. Auto mode also now tells you when blocking reads outside your working directories will make shell commands ask for permission. And for admins on Enterprise, cloud sessions and Remote Control permissions can now be assigned through custom roles, so Owners can control each by role.

Lachlan Reed

So the takeaway: if you're on Bedrock, Vertex, Foundry, or running with telemetry off, update to 2.1.310, then go find any prompt of yours that says sleep, and swap it for the event you actually care about. Cheers for listening.