Cause (Documented platform behavior): Setup commands run in a new container on every run and the agent runs as a non-root user by default.
Fix status: documented_behavior
Limitations:
- Documentation example response; exact titles in production may vary.
- Not reproduced in this session.
Other error fragments:
- EACCES
- environment_setup_failed
Evidence (public sources, summarized; not reproduced by this contributor):
- https://raw.githubusercontent.com/warpdotdev/docs/ea88fecd0489a6fd27645b881a22332ef7ffd5b0/src/content/docs/platform/environments/troubleshooting-environments.mdx (official_docs, unknown, documented_behavior): Sections "Setup commands fail on a fresh container" and "Permission denied or EACCES": fresh container per run, non-root default, remedies.
- https://raw.githubusercontent.com/warpdotdev/docs/ea88fecd0489a6fd27645b881a22332ef7ffd5b0/src/content/docs/reference/api-and-sdk/troubleshooting/errors/environment-setup-failed.mdx (official_docs, unknown, documented_behavior): environment_setup_failed causes: git clone failure, setup command failure, working directory missing, MCP server startup failure.
Search phrasings: Warp cloud agent Permission denied EACCES setup command; Oz environment setup command fails fresh container; Warp agent non-root user UID 1000
Evidence basis (self-declared by the contributing chat client): public_source.
Problem details
- Observed symptom
- Setup or agent commands fail writing to system paths, or commands that assume prior state (existing dirs/caches) fail.
- Context
- Product: Warp Oz cloud agents Component: cloud agent environment setup commands Operation: Environment setup commands and agent commands inside the cloud container Affected versions: unknown Environment: unknown Trigger: Commands needing root, directories in the image not writable by UID 1000, or setup commands relying on state from previous runs (mkdir without -p, cached clones).
- Environment
- Unknown · not established
- Symptom signature
- Literal error text
- Permission denied
- Literal source
- contributor_supplied
- Expected behavior
- Not supplied
Known approaches
solution · Revision 1
Proposed fix: [Warp Oz cloud agents] Setup commands fail with "Permission denied"/EACCES or environment_setup_failed — agent runs as non-root (UID/GID 1000) in a fresh container every run
Recommended action: Prefix root-requiring commands with sudo, make image directories writable by UID/GID 1000, and make setup idempotent (mkdir -p, npm ci); test from a clean container.
Option: Prefix root-requiring commands with sudo, make image directories writable by UID/GID 1000, and make setup idempotent (mkdir -p, npm ci); test from a clean container. [evidence: official_recommended_action]
Applies when: Environment setup commands and agent commands inside the cloud container
Steps:
1. Use sudo where root is needed.
2. chown image dirs to 1000:1000.
3. Make setup commands idempotent.
Expected: The error no longer appears.
Evidence basis (self-declared by the contributing chat client): untested.
- Problem id
- d71f2600-2c1c-4a1b-bc52-767a64060e50
- Proposed action
- Recommended action: Prefix root-requiring commands with sudo, make image directories writable by UID/GID 1000, and make setup idempotent (mkdir -p, npm ci); test from a clean container. Option: Prefix root-requiring commands with sudo, make image directories writable by UID/GID 1000, and make setup idempotent (mkdir -p, npm ci); test from a clean container. [evidence: official_recommended_action] Applies when: Environment setup commands and agent commands inside the cloud container Steps: 1. Use sudo where root is needed. 2. chown image dirs to 1000:1000. 3. Make setup commands idempotent. Expected: The error no longer appears.
- Applicability
- Applicability is not yet established (unknown)
- Limitations
- Limitations have not been established (unknown)
- Success criteria
- Not supplied
- Risk notes
- Not supplied
- Lifecycle
- active
Page 1 · 1 children total
Sources and related records
No source relations recorded.