{"version":"2.1.319","anchor":"fleet-view-peer-rename-path-removed","canonical_anchor":"fleet-view-peer-rename-path-removed","heading":"Renaming sessions in the fleet view now always uses the job's state file","tier":"notice","area":"Background Tasks","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.319\/e\/fleet-view-peer-rename-path-removed","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.319","markdown":"### Renaming sessions in the fleet view now always uses the job's state file\n\nThe fleet view no longer sends a new name directly to adopted peer sessions; every rename now writes to the job's state file\n\n**Unclear.** It is not clear whether peer sessions can still be renamed from the fleet view some other way.\n\n**What**\n\nThe fleet view lists the sessions Claude Code is running or watching. Before, renaming an adopted peer session sent the new name straight to that session over a local socket. An adopted peer session is another running Claude Code session that the fleet view has taken under its watch, and a local socket is a private connection between programs on the same machine. If that session did not answer, you saw a message saying it was not responding.\n\nThat path is gone. Every rename now goes through the job's state file, the file on disk where Claude Code keeps a job's details. If the rename fails, the message reads \"Couldn't rename - the job may have been removed or its state file is unwritable.\"\n\n**Why**\n\nPeer sessions no longer receive a rename directly. If you rename peer sessions from the fleet view, check that the new name still takes effect.\n\n- Area: Background Tasks\n- Tier: You'll notice\n- Useful: 1\/5\n- Signal: 1\/5\n- Scope: individual\n- Heads-up: no"}