{"version":"2.1.224","anchor":"failed-peer-listings-are-reported-rather-than-looking-empty","canonical_anchor":"failed-peer-listings-are-reported-rather-than-looking-empty","heading":"Failed peer listings are reported rather than looking empty","tier":"notice","area":"Cross-Session Messaging","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.224\/e\/failed-peer-listings-are-reported-rather-than-looking-empty","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.224","markdown":"### Failed peer listings are reported rather than looking empty\n\nA failed peer listing is now reported as a failure rather than an empty roster.\n\n**What**\n\nWhen Claude Code cannot list the other sessions it can reach, the failure is now recorded as a failure instead of coming back as an empty roster. This matters for the ListAgents tool, which only records what the model saw when the listing actually succeeded.\n\n**Details**\n\n- Failure is set when auth preparation throws, when the list request throws, or when the server returns a non-200 status.\n- Logs `[bridge:peers] auth prep failed:`, `[bridge:peers] list request failed:` and `[bridge:peers] list failed`.\n- The population fetch carries the failure flag through and logs a \"FAILED, not recordable\" marker.\n\n**Evidence**\n\n`[bridge:peers] auth prep failed:`\n\n- Area: Cross-Session Messaging\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 3\/5"}