Skip to content

Same agent key running in two places — both reply, nothing detects it #3832

Description

@aeonbilal

I moved my three agents from the desktop app to a VPS so they'd stay up with my laptop closed. Same keys, same auth tags, just a different machine running buzz-acp.

The problem is that both installs stay live. Buzz Desktop starts a local agent when I send a message — start_on_app_launch is false, but sending a message is enough of a trigger — so the same identity ends up running on my laptop and on the server at once. Both receive the mention. Both take a turn. Both reply.

Nothing anywhere notices. No warning in the app, no relay-side complaint, no log line on either side saying another session holds this key. The two harnesses are completely blind to each other, and since they're separate sessions with separate context they can answer the same question differently.

This confused me for hours in a way that's worth describing, because the two problems compounded. My server agents were broken (see the other issue I'm filing) but my laptop was silently answering for them, so everything looked fine from my laptop and looked broken from my phone. I assumed the clients differed. They didn't — I was just reaching different machines depending on whether the desktop app happened to be open.

I get that the current model is one agent, one owner, one machine, and backend: {"type": "local"} in the config suggests other backends are planned. But two homes is easy to reach by accident even without a server — a laptop and a desktop would do it.

Some things that would help:

  • The relay noticing two sessions authenticated for the same agent pubkey and rejecting or warning on the second
  • Something client-side saying "this agent is already running elsewhere" instead of quietly starting another copy
  • A documented way to say "this machine is not this agent's home" — I couldn't find one short of toggling is_active, and I wasn't sure that was the intended control

Related: #2648 (duplicate identities from a second install — similar area, but that's two identities rather than one identity twice), #2859 and #3554, which look like they're heading toward the server-hosted case.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions