Two Claude Agents, One iMessage Number, No Duplicates

Because the deciding step, whether to call Claude and reply, moves from a fixed, single threaded pipeline into however many processes you happen to have running. A single webhook handler, one process, one Beam line, has no race to lose: it reads the event, calls Claude once, sends once, done. Add a second process pointed at the same workspace, for any ordinary reason, and you have a race with no referee unless you build one.

The reasons are mundane, not exotic. Horizontal scaling puts workers behind a queue for throughput, and a redelivered event after a slow acknowledgment reaches a different worker than the one still finishing the first attempt. A deploy overlap brings a new build up before the old one drains its in-flight work, so both are briefly live against the same webhook secret. A resumed session happens when an agent crashes mid reply, a supervisor restarts it, and the restarted session re-reads the same inbound event, not knowing a reply may already be in flight.

None require bad code elsewhere in your stack. They need one missing piece: something that lets only one process claim a conversation before calling Claude, and makes every other one stand down. Anthropic's own issue tracker shows what happens without that piece, in a different context: a GitHub issue on Claude Code describes .claude.json corruption from running five or more Claude Code instances at once, each writing the same shared config file with no file locking between them (anthropics/claude-code#28847). The resource is different, a config file instead of a text thread, but the shape of the bug is the one we are fixing here: more than one process touching one shared thing with no coordination.

Here is a webhook handler that claims the conversation before it starts a Claude turn, written against a Postgres table rather than a new dependency, since most teams running a Beam integration already have a database:

create table if not exists conversation_claims (
  conversation_key text primary key,
  claimed_by text not null,
  claimed_at timestamptz not null default now(),
  expires_at timestamptz not null
);

import os

WORKER_ID = os.environ["WORKER_ID"]
LOCK_SECONDS = 90  # longer than the slowest realistic Claude turn for this workflow

def claim_conversation(conn, conversation_key: str) -> bool:
    with conn.cursor() as cur:
        cur.execute(
            """
            insert into conversation_claims (conversation_key, claimed_by, expires_at)
            values (%s, %s, now() + interval '%s seconds')
            on conflict (conversation_key) do update
              set claimed_by = excluded.claimed_by, claimed_at = now(), expires_at = excluded.expires_at
              where conversation_claims.expires_at < now()
            returning claimed_by
            """,
            (conversation_key, WORKER_ID, LOCK_SECONDS),
        )
        row = cur.fetchone()
        conn.commit()
        return row is not None and row[0] == WORKER_ID

The on conflict ... where expires_at < now() clause is the part that matters. A fresh key claims cleanly on the insert. One already held by a live claim fails the update's where condition, so nothing changes and returning comes back empty, which the calling code reads as "someone else owns this, stand down." One whose claim already expired, because the holder crashed or ran long, is free for whoever asks next.

Diagram: a sequence diagram with two parallel lanes labeled "Process A" and "Process B," both receiving the same inbound webhook arrow at the same vertical height; Process A's lane shows a green "claim succeeded" box flowing down into "call Claude" then "send reply"; Process B's lane shows a red "claim failed" box at the same height that dead-ends immediately with no further boxes below it.

A resumed Claude Agent SDK session raises the same question from a different angle: not "did two processes see this event," but "did this one process already act on this before it crashed." The fix is the same claim, checked at the same point, just triggered by a restart instead of a second worker. Before resuming or replaying any in-flight turn, the process should attempt to claim the conversation key exactly as a fresh webhook delivery would. If the claim fails because a still-live process already holds it, the restarted session should not resume that turn.

This differs from what our custom send_text tool guide covers. That guide's idempotency key protects one process against its own retries, the same process calling its own tool twice for one intended send. Crashing and restarting means a new process instance picking up where an old one stopped, and the old claim may or may not still be valid depending on timing. Treat a restart as a new claim attempt, never a continuation automatically allowed to proceed.

Run this against a test Beam workspace, never a live client line, before any lock you build gets near a real contact.

1. Stand up your webhook handler with the claim table above, and set LOCK_SECONDS to a short value you can watch pass in real time, such as twenty.
2. Start one copy as WORKER_ID=a, text the connected test number once from your own phone, and confirm exactly one reply arrives with WORKER_ID=a logged as the claim winner.
3. Before that claim window lapses, replay the same webhook payload as WORKER_ID=b and confirm the claim attempt returns false, with no second Claude call or send.
4. Wait past the claim window, replay the identical payload as WORKER_ID=b again, and confirm the claim now succeeds, since the earlier claim lapsed; this matches a real crash-recovery case, not a test failure.
5. Start a second live copy as WORKER_ID=c running at the same time as WORKER_ID=a, both against the same test workspace and database, then text the number once more; only one copy should log a successful claim and a sent reply.
6. Kill whichever process holds the live claim while Claude is still composing a reply, then confirm the other copy claims that same key once the expiry passes without repeating the unfinished reply.
7. Check the Beam inbox for that test contact directly, not just your own logs, and confirm the thread shows exactly one reply per inbound text, since the inbox is what a contact actually sees.
8. Only after steps one through seven pass clean, point the same setup at a small slice of real contacts, and watch the claim table for any row still claimed well past its expiry, which usually means a handler is hanging rather than crashing.

Beam is an independent messaging platform, not an Anthropic or Apple product, and the locking pattern above runs in your own service, not inside Beam or Claude. Still deciding whether to build this webhook layer yourself or start from a working iMessage API? Our build your own iMessage API guide covers that setup decision first. Once more than one agent process needs to share request budget as well as conversation ownership, pair this guide with our MCP rate limit guide; deciding between a self hosted MCP server and calling Beam's REST API directly from your claim-checked handler, see our iMessage MCP server guide. For what to do when a webhook delivery never arrives at all, rather than arriving twice, see Beam's missed webhook recovery guide.