jonny (good kind) on Nostr: Something I'm trying to track down is how this remote claude session thing works. A ...

Something I'm trying to track down is how this remote claude session thing works. A general pattern in the claude code source is that more recent features are implemented in a way more chaotic way than more "core" features, which reflects the nature of vibe coding: because you don't have a solid foundation, and there is a progressive layer of crust and special cases, the only real way to add more features is to keep adding more crust and special cases. Like rather than having a set of blocks that are self contained and you add another block, you need to slice across all the prior blocks and add something to each of them.

There are a number of places, both in comments and code, that rely on "this session is running in claude code remote session" in some VM, and so therefore they use the filesystem for state (e.g. [storing the api and oauth keys](https://neuromatch.social/@jonny/116345270216954323 )), but those parts of the code are in no way cleanly isolated from the rest of the code. So I suppose if i were a pentester or security auditor or whatever what i'd be looking for is places where the mashup of "in remote session / not in remote session" assumptions fails, and we do something naughty on the host system rather than a VM. Like I said still reading, just sort of musing about some of the problems with the package that are larger than individual functions and features.

quoting
note14mc…psrh

FOR EXAMPLE:

In the claude code remote feature it is sometimes possible for the means of passing auth credentials to fail. So claude code has a fallback of *writing the API key or OAUTH token to a single well-known file* because *sometimes* one of the several means of inheriting the fucking most important secret information in the entire thing doesn't work.

I'm not a security person but that seems like a pretty bad thing to do that maybe someone should look into.