Make is_vscode() non-blocking to prevent HTTP timeout on new sessions

[skaar]

I've seen unrecoverable sessions hitting this is_vscode check with Claude Code to the point where the interaction with the application stops working. Claude Code does send clientInfo, but it may make assumptions about when it has already sent the initialization message.

[benh]

Can you repro this and then share some logs so I can better understand what the bug is? Thanks!

[skaar]

Can you repro this and then share some logs so I can better understand what the bug is? Thanks!

I don't think the change and test in this PR are valid for the problem I'm observing. At some point I end up with a session that doesn't have client_info.

When this happens, we can also observe the session replay in the log when the server is restarted. I will keep on looking for how we might end up in this state. At the moment, I don't know if the session ever had client_info and somehow lost it, or if it was created without client_info.

[skaar]

This might have gone away with the del self._write_request_ids[event_id] change in 0.6.0. After bringing the trouble application up to data, I can't reproduce this.

I did go down the path of returning -32600 (INVALID_REQUEST) if the client had not initialized. This goes against the stateless=True we are operating with, and clients like claude code are not handling the rejection gracefully - they are unable to recover from this.

I plan to close this out unless I run into this the next few days.