Running this from a cloud session? Share your setup

[fcavalcantirj]

If you're running this skill from a cloud session rather than a local Claude Code — Cowork, a remote/bridged session, a dev container, anything where Claude isn't on the same network as your camera — I'd like to hear how it went.

Why: a bridged session often has an egress proxy for public destinations and no route to your LAN at all. Nothing in snap.sh can create a route that doesn't exist, so the honest ask is upstream: let a bridged session reach LAN devices. That request lands much better with several real users behind it than with one.

Details and a one-command triage are in #2.

If you hit it, please post:

1. Which product / session type (Cowork, remote session, container, …)
2. claude --version and curl --version
3. The result of both of these, from wherever snap.sh actually runs:

   curl -s -o /dev/null -m 6 -w 'via-proxy=%{http_code}\n' "http://<camera-ip>:8080/shot.jpg"
   curl -s -o /dev/null -m 6 --noproxy '*' -w 'direct=%{http_code}\n' "http://<camera-ip>:8080/shot.jpg"

   direct=403 means a proxy refused you. direct=000 means there's no route — the unfixable one.
4. Any proxy response headers (curl -D -), especially anything like X-Proxy-Error
5. What you ended up doing instead, if anything worked

Already fixed, so update first (v1.1.1): LAN addresses are no longer sent through a proxy, a 403 is no longer blamed on the wrong system, and CRLF line endings can no longer kill the script on a Windows clone. If you tried this before v1.1.1, it's worth retrying.

Mask your camera password if you paste any config.