[BUG] Code tab environment filter returns the opposite set of sessions

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

In the Code tab, filtering the session list by environment returns the wrong group:

• Filtering by Local shows only sessions running on a remote SSH host
• Filtering by Remote Control shows only sessions running locally on this laptop

The two sets appear to be swapped. Clearing the filter shows everything, and every session opens and works correctly, so this looks like filtering or classification rather than a problem with the sessions themselves.

What Should Happen?

Local lists sessions running on this machine, and the remote filters list sessions that are not.

Error Messages/Logs

Steps to Reproduce

1. Start at least one Claude Code session locally on the laptop.
2. Add an SSH connection and start at least one session on the remote host, so the Code tab has both kinds.
3. Open the Code tab session list and filter by Local.
4. Only the remote SSH sessions are listed.
5. Change the filter to Remote Control.
6. Only the local sessions are listed.
7. Clear the filter; everything is listed as expected.

Claude Model

_No response_

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.56 (Claude Code); Claude Desktop 1.40609.0

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

With a mix of local and remote sessions open, the filter is the quickest way to find the one you want, and it reliably returns the other group. It is also easy to misread as sessions having been lost or started in the wrong place.

I do not know how sessions are bucketed internally. One guess is that SSH sessions, being neither cloud sessions nor Remote Control sessions, fall into a default bucket the filter then labels incorrectly, but that is speculation. The observed behaviour above is what I can confirm.

Desktop app version: 1.40609.0.