Cloud routine sandbox: local LFS proxy at 127.0.0.1:37713 returns HTTP 502 on every git lfs pull

Summary

In the Claude Code cloud routine execution sandbox, git lfs pull consistently fails with HTTP 502 against the loopback LFS proxy that the sandbox configures. This blocks every routine that depends on Git LFS objects (book page JPEGs, large filings PDFs, etc.) from making progress — sub-agents only see 130-byte LFS pointer stubs and fail with 400 Could not process image when handed to multimodal vision.

Environment

• Surface: Claude Code cloud routine (scheduled / on-demand remote agent), not local Claude Code
• Repo: private, uses Git LFS for *.jpg page scans and *.pdf filings
• LFS proxy URL observed inside sandbox: http://127.0.0.1:37713/git/<owner>/<repo>.git/info/lfs/objects/batch

Reproduction

1. Have a repo that tracks files via Git LFS (.gitattributes with filter=lfs diff=lfs merge=lfs).
2. Schedule any cloud routine that does git lfs pull (or that reads an LFS-tracked file as bytes).
3. Observe: git lfs pull returns Fatal error: Server error … from HTTP 502 from the 127.0.0.1:37713/...info/lfs/objects/batch endpoint.
4. Retries with exponential backoff (we tried 2s/4s/8s/16s, 4 attempts) all 502.

Evidence

Public PR with the failure trace and full routine output: https://github.com/huahang/investment-notes/pull/136

Relevant excerpt from the routine's BLOCKED report:

git lfs pull against http://127.0.0.1:37713/git/huahang/investment-notes.git/info/lfs/objects/batch returned Fatal error: Server error … from HTTP 502 on every attempt, including 4 retries with 2s/4s/8s/16s exponential backoff. raw/books/guns-germs-and-steel/pages/page_*.jpg files are 130-byte LFS pointer stubs (e.g. oid sha256:4ee9d2b0…f87b6, expected size 69 049). Sub-agents that tried to read them failed with 400 Could not process image.

Impact

• All cloud routines that depend on LFS-tracked content cannot make progress.
• Routines that correctly handle the failure (no PDF fallback, no --force) end up filing zero-progress BLOCKED PRs each run, polluting repo history with empty markers.
• Workarounds inside the repo (re-routing to media.githubusercontent.com, vendoring scripts) are possible but feel like patching around a sandbox-side bug.

Expected behavior

Either:

1. The sandbox pre-pulls LFS objects when cloning the repo (so git lfs pull is a no-op inside the routine), or
2. The loopback LFS proxy at 127.0.0.1:37713 is reliably available and proxies batch requests through to GitHub LFS without 502.

Asks

• Confirm whether this is a known sandbox-side issue.
• If LFS support in cloud routines is intentionally not provided, please document that constraint so users can design around it from day one (e.g. avoid LFS in repos that are routine targets, or vendor a media.githubusercontent.com fallback in the routine prompt).
• If LFS is supposed to work, please surface the proxy logs / fix the 502.

Thanks!