Cross-session messaging, the feature that lets one Claude Code session pass a note to another with ListAgents and SendMessage, launched in v2.1.224 with a specific, documented gap: it explicitly did not work on Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform, or Microsoft Foundry, and it turned off if any of the environment variables that disable Claude Code's telemetry were set. Claude Code v2.1.248, released 27 August 2026, closed that gap. Its own changelog entry states it plainly: "Added cross-session messaging (SendMessage / ListAgents) between sessions on the same machine on Bedrock, Vertex, and Foundry, and when telemetry is disabled."
If you run Claude Code against one of these providers, or with telemetry turned off for compliance reasons, this is worth knowing about even if you never read the original feature's documentation closely enough to notice the exclusion. A capability that genuinely didn't exist on your setup a few weeks ago now does, with no configuration required beyond updating.
What was actually blocked, and why
Same-machine cross-session messaging works over a local channel, a Unix domain socket on macOS and Linux, a named pipe on native Windows, and never routes through Anthropic's servers at all. That's worth stating up front because it means the provider restriction was never about the message needing to reach Bedrock, Vertex, or Foundry's own infrastructure. The actual mechanism, one session's inbox socket receiving a message from another session on the same disk, doesn't care which provider either session authenticates against.
What did matter is that cross-session messaging depends on Claude Code's feature-flag evaluation to determine whether a given session has the capability turned on at all, the same mechanism behind many staged rollouts. That evaluation wasn't reaching sessions running against Bedrock, Vertex, or Foundry, or sessions with telemetry disabled via CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, DISABLE_TELEMETRY, DO_NOT_TRACK, or DISABLE_GROWTHBOOK. The delivery mechanism was ready from the feature's original launch; the gate deciding who got to use it wasn't reachable from those configurations. v2.1.248's fix was specifically to same-machine messaging on these providers and in these configurations, which the changelog scopes precisely: it doesn't claim anything changed about messaging to sessions beyond the local machine.
Who this actually affects
This matters most to exactly the kind of organization that was already likely to be running one of these providers or disabling telemetry in the first place: regulated enterprises on Amazon Bedrock or Microsoft Foundry for compliance reasons, teams on Google Cloud's Agent Platform for existing GCP commitments, and any organization that disables Claude Code's telemetry as a matter of policy regardless of provider. These are exactly the users least likely to be running Claude Code against the plain Claude API with default settings, and until v2.1.248 they were also, as a direct consequence, the users least able to use a feature that had already been generally available for three weeks.
If your organization runs Claude Code fleets against Bedrock, Vertex, or Foundry and has been waiting on cross-session messaging to coordinate work across parallel sessions, checking your rollout version is worth doing now rather than assuming the original launch's provider list is still accurate.
Confirming it actually works on your setup
The check is the same one Claude Code's own documentation recommends for cross-session messaging generally, and it still applies here:
claude --version
Confirm you're on v2.1.248 or later. Then, inside a running session:
/list-agents
/list-agents (aliased /peers) lists this session's own name on the first line, when it has one, followed by every session Claude can currently reach. If the command isn't recognized at all, the session doesn't have cross-session messaging, whatever the version, since the command itself only exists once the feature is present. If it runs but lists nothing beyond this session, that's a narrower problem, worth checking against the full cross-session messaging troubleshooting guide rather than assuming the provider is still the blocker.
There's nothing to enable beyond the version bump. Same-machine messaging on these providers works the same way it works everywhere else once a session qualifies: automatically, with crossSessionInbound and the usual inbound controls governing what arrives, exactly as they do on any other provider.
What still doesn't work here
This release fixed same-machine messaging specifically. Two related capabilities remain out of reach on these providers, and it's worth being precise about the boundary so you don't assume more changed than actually did:
- Sessions beyond this machine. Reaching a session on another of your machines, or a Claude Code on the web session, requires Remote Control, which needs a claude.ai sign-in as the session's active authentication. Claude Code's documentation is direct that Claude still can't find those sessions with an API key, or on Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform, or Microsoft Foundry, full stop. If your Bedrock sessions authenticate through AWS rather than a claude.ai sign-in, which is the normal setup, cross-machine messaging and Remote Control generally stay unavailable regardless of this fix.
- Older claims about provider availability. The original cross-session messaging explainer and the notify_when_idle guide were both written before v2.1.248 and describe Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform, and Microsoft Foundry as unsupported. Claude Code's current documentation states availability in general terms, covering the whole messaging mechanism these two articles describe, so treat their specific provider callouts as superseded by this release rather than still current, and check
/list-agentson your own setup instead of relying on either article's dated wording.
A worked example
Say your organization runs Claude Code against Amazon Bedrock for two sessions on the same build machine, one migrating a database schema and one building the API layer that depends on it, a scenario that's a natural fit for cross-session messaging but was simply unavailable on Bedrock before v2.1.248. After updating both sessions past that version, the migration session can tell the API session the moment it finishes without anyone copying output between terminals:
Let the session working on the API layer know the schema migration is done and the new column is tenant_id
This works exactly the way it would on the plain Claude API: Claude finds the target with ListAgents, delivers with SendMessage, and the receiving session's crossSessionInbound setting decides whether the message is delivered outright, held for approval, or refused. Nothing about running on Bedrock changes that flow now that the feature is actually present.
Why this kind of gap is worth watching for generally
This isn't the first time a Claude Code feature's provider list has moved after launch, and it's unlikely to be the last. New capabilities routinely ship first for the plain Claude API and pick up Bedrock, Vertex, and Foundry support in a later release once the underlying mechanism is verified against those providers' own authentication and networking models. /radio followed the same pattern in the same release that fixed cross-session messaging: v2.1.248's changelog also records it becoming "available on Bedrock, Vertex AI, Foundry, and Claude Platform on AWS, and when telemetry is disabled," worded almost identically to the cross-session messaging fix, which suggests both were unblocked by the same underlying change to how Claude Code enables features on these providers rather than two unrelated fixes that happened to land together.
The practical lesson for an organization standing up Claude Code on one of these providers is to treat a documented exclusion as a snapshot, not a permanent limitation, and to re-check it periodically against the current documentation or changelog rather than assuming a gap noted at rollout is still there months later. A feature's own dedicated page is the right place to check, not a secondary source or an older article, including ones on this site, since exactly this kind of provider-availability detail is what tends to go stale fastest as Anthropic backfills support.
Troubleshooting
/list-agents still isn't recognized after updating. Double-check the version actually took effect in the running session; a long-lived background session started before the update may still be on the old binary until it's restarted or resumed fresh. Run claude --version from a new terminal invocation, not inside an already-running session, to confirm what's actually installed.
Messaging works locally but not to my other machine. That's expected on these providers. Cross-machine messaging requires Remote Control, which requires a claude.ai sign-in as the session's active authentication, something Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform, and Microsoft Foundry sessions don't use. This release didn't change that requirement.
Telemetry is disabled for compliance reasons, and I'm not sure this still qualifies. It does. The v2.1.248 changelog names "when telemetry is disabled" as its own qualifying case, separate from the four providers, so a session using the plain Claude API with DISABLE_TELEMETRY set (or any of the other telemetry-disabling variables) gets the same fix regardless of provider.
I want to turn this off now that it's available. The controls are unchanged: set crossSessionInbound to refuse to stop receiving, and add permission deny rules for SendMessage and ListAgents to stop sending and listing, the same as on any other provider. See how Claude Code sessions message each other for the exact settings.
Where to go next
For the full mechanics of cross-session messaging, discovery, delivery, and inbound controls, see how Claude Code sessions message each other. For the one-shot idle notice built on the same mechanism, see get notified when another session goes idle. Browse the full Claude Code catalog at getclaudeskills.com/platforms/claude-code.
Verified 30 August 2026 directly against Claude Code's cross-session messaging documentation at code.claude.com, read in full, including its Availability section confirming per-provider requirements, and the v2.1.248 changelog entry (27 August 2026) that introduced same-machine messaging on Bedrock, Vertex, Foundry, and telemetry-disabled sessions.
