Remote daemon rejects gzipped artifact uploads — every install fails with "Invalid tar header … needs to be gunzipped"

[brentvatne]

Summary

Since roughly 2026-08-10 23:40 UTC, every agent-device install against a remote (EAS-hosted) session daemon fails at the artifact upload:

Error (COMMAND_FAILED): Upload failed: {"ok":false,"error":"Invalid tar header. Maybe the tar is corrupted or it needs to be gunzipped?","code":"UNKNOWN"}

The CLI is fine. The daemon appears to have lost gzip decompression for artifact uploads. It accepts an uncompressed tar of the same bundle, and rejects every gzipped one — which is a problem because the CLI always gzips.

Reproduced on 0.20.6 and 0.20.7, on both an Expo Go install and an EAS development-build install, across ~8 sessions.

Evidence

agent-device builds its payload with tar czf and posts it to POST <daemon>/upload with content-type: application/gzip, x-artifact-type: app-bundle (agent-device-client.js). I replayed exactly that request against a live session daemon with controlled payloads — a minimal Probe.app containing one file — varying only the encoding:

payload	content-type	daemon response
gzipped tar (GNU, i.e. what the CLI sends)	application/gzip	500 Unexpected end of data
gzipped tar (pax)	application/gzip	500 Unexpected end of data
gzipped tar (ustar)	application/gzip	500 Unexpected end of data
gzipped tar, ~1 MB payload	application/gzip	500 Invalid tar header. Maybe the tar is corrupted or it needs to be gunzipped?
uncompressed tar	application/x-tar	200 {"ok":true,"uploadId":…}
uncompressed tar	application/gzip	200 {"ok":true,"uploadId":…}

Reading, in order:

1. It is not a tar format problem — GNU, pax and ustar all fail identically while gzipped.
2. It is not the content-type header — an uncompressed archive is accepted even when labeled application/gzip, so the receiver is sniffing the bytes.
3. The ~1 MB gzipped case reproduces the exact production error string, so the small-payload Unexpected end of data and the user-visible Invalid tar header… are the same fault at different sizes.

Together these say the receiver is treating gzipped input as if it were a plain tar — i.e. the decompression step is missing or no longer reached.

Impact

Every remote-daemon install is broken: install, and anything that installs first (Expo Go boots, dev-build installs). Local daemons may be unaffected — I could only test the hosted path.

Workaround (for anyone blocked)

The CLI shells out to bare tar, so a shim earlier on PATH that rewrites czf → cf makes it emit an uncompressed archive, which the daemon accepts:

#!/bin/sh
if [ "$1" = "czf" ]; then shift; exec /usr/bin/tar cf "$@"; fi
exec /usr/bin/tar "$@"

Uploads are then uncompressed, so transfers get bigger — fine as a stopgap, not a fix.

Environment

• agent-device 0.20.6 and 0.20.7 (same result)
• Client: Linux (Debian, node 24), GNU tar
• Daemon: EAS-hosted iOS simulator session (type: AGENT_DEVICE), reached over the session's tunnel
• Same code path worked earlier the same day (2026-08-10 ~05:20 and ~11:23 UTC) with no client change in between

Happy to re-run the probe against a session if you want additional variants tested.

[thymikee]

Triaged as an actionable remote-daemon install outage. The supplied matrix strongly isolates the failure to hosted artifact ingestion before tar parsing: gzip payloads fail across tar variants, while plain tar succeeds even when labeled gzip. Because the same 0.20.6/0.20.7 clients worked earlier without a client change, the first owner action is to inspect the EAS-hosted daemon deployment/configuration around 2026-08-10 23:40 UTC and verify the gzip detection/decompression route. No additional reporter information appears necessary yet; keeping needs-triage until the hosted-service owner confirms ownership.

[thymikee]

We've pushed some security-related fixes in latest 2 releases so that's probably this. Investigating and will provide a fix for that today