Custom MCP connectors don't appear in /schedule routine-attachment connector list despite showing "Connected" in Settings

Summary

Added a custom MCP connector (Robinhood Trading, https://agent.robinhood.com/mcp/trading) at claude.ai/customize/connectors, completed full OAuth, and it shows a green "Connected" status in the Settings UI. However, the /schedule skill's routine-creation flow ("Available MCP Connectors" section) consistently reports "No available MCP connectors found."

Steps to reproduce

1. Add a custom MCP connector via claude.ai/customize/connectors with a custom server URL (not a marketplace/first-party connector).
2. Complete the OAuth flow fully; confirm it shows "Connected" in the connectors list UI.
3. Start a routine-creation flow (via the /schedule skill or equivalent) and check the available MCP connectors for attachment.

Expected: The connected custom connector appears in the list, available to attach to a routine via mcp_connections.

Actual: The connector list returns empty ("No available MCP connectors found"), even though the same connector shows connected in account settings.

Reproduction detail

• Reproduced across 4 separate checks over roughly 30 minutes.
• Includes one check after a full disconnect and reconnect of the connector (to rule out a stale/partial registration from the first OAuth attempt).
• A first-party connector (GitHub Integration, connected via the separate GitHub App install flow) worked fine for its purpose (repo access for routines) — so this appears specific to custom (non-marketplace) connectors not surfacing for mcp_connections attachment specifically, not a general connectors-page issue.

Possibly related (separate issue, noting in case it's the same root cause)

A bridge-kind environment (tied to a local claude --remote-control session on the same machine) also failed in a related way:

• Routines targeting the bridge environment reported success at the platform/API level (last_fired_at populated, run marked as succeeded) but never actually executed against the local filesystem — confirmed via file-timestamp checks after both a scheduled fire and a manual RemoteTrigger run while the local session was confirmed active.
• Restarting the local claude --remote-control session did not reconnect to the existing bridge environment — it orphaned it. A subsequent manual run against the old environment ID returned HTTP 400 environment_not_found, and the environment no longer appeared in the schedule skill's environment list at all afterward (not replaced by a new one either).

Environment

• Platform: macOS (darwin-arm64), Claude Code native install
• This was all done via an interactive Claude Code session driving the RemoteTrigger tool / /schedule skill on behalf of the user.