PR #73341: fix(acpx): tolerate fs.chmod EPERM on remote/special filesystems (#73333)

• Repository: openclaw/openclaw
• Author: Sanjays2402
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/73341

Description (problem / solution / changelog)

Summary

• Problem: acpx plugin startup aborts with EPERM: operation not permitted, chmod '…/codex-acp-wrapper.mjs' when OPENCLAW_STATE_DIR (or ~/.openclaw) lives on a filesystem that rejects chmod — common on some NFS/SMB mounts, hardened cloud storage, and read-only-perms volumes (issue #73333). The wrapper file itself is already written successfully when the chmod failure throws.
• Why it matters: ACP wrappers are always invoked via node /path/to/wrapper.mjs, so the executable bit is purely cosmetic. The plugin had no reason to die here, but it did, taking the entire acpx-runtime plugin service with it.
• What changed: Wrap both fs.chmod calls in extensions/acpx/src/codex-auth-bridge.ts (writeCodexAcpWrapper, writeClaudeAcpWrapper) in a small chmodWrapperBestEffort helper that swallows EPERM / EACCES / EROFS / ENOSYS / ENOTSUP and rethrows everything else.
• What did NOT change (scope boundary): No change to wrapper script content, prepareAcpxCodexAuthConfig API, ACP launch command building, codex-auth handling, or any other plugin. No new config knob.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Skills / tool execution <!-- acpx plugin runtime -->
• Gateway / orchestration
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #73333
• Related #
• This PR fixes a bug or regression

Root Cause

• Root cause: writeCodexAcpWrapper and writeClaudeAcpWrapper always called await fs.chmod(wrapperPath, 0o755) after writing the file. On filesystems that disallow chmod on regular files, fs.chmod rejects with EPERM (or EACCES, depending on the FS), which propagates up through prepareAcpxCodexAuthConfig and aborts acpx-runtime.start() — even though the wrapper file is on disk and would launch correctly via node.
• Missing detection / guardrail: The wrapper-write path treated chmod as required for execution, but the wrapper is never executed directly — only via process.execPath (Node) — so the executable bit is decorative.
• Contributing context (if known): Reported on Ubuntu 24.04 with the OpenClaw state dir on a remote/cloud-mounted volume (/home/node/.openclaw). The same pattern reproduces on read-only-perms NFS / SMB mounts. Surfaces in self-compiled deployments where state dir placement is more flexible than the canonical ~/.openclaw on local disk.

Regression Test Plan

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: extensions/acpx/src/codex-auth-bridge.test.ts.
• Scenario the test should lock in: prepareAcpxCodexAuthConfig must succeed (and produce wrapper files) even when fs.chmod rejects with EPERM / EACCES / EROFS / ENOSYS / ENOTSUP; unexpected errnos (e.g. ENOSPC) must still propagate.
• Why this is the smallest reliable guardrail: The bug is isolated to one helper that runs once per plugin start; mocking fs.chmod with vi.spyOn catches both the Codex and the Claude wrapper paths and asserts the file is still on disk afterward.
• Existing test that already covers this (if any): None — existing tests only assert the happy path on a writable temp dir.
• If no new test is added, why not: N/A.

User-visible / Behavior Changes

acpx plugin no longer fails to start on filesystems that reject chmod. No config / API change. On every other filesystem, behavior is byte-identical.

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No — the wrapper is still spawned via node <path>; not having +x on it does not introduce any new surface.
• Data access scope changed? No

Repro + Verification

Environment

• OS: macOS 26.5 (Apple Silicon) for unit tests; original report on Ubuntu 24.04.1 LTS.
• Runtime/container: local pnpm workspace, Node 25.9, vitest.
• Model/provider: N/A.
• Integration/channel (if any): acpx-runtime plugin.
• Relevant config (redacted): N/A — bug is in plugin startup, not user config.

Steps

1. On origin/main: pnpm vitest run extensions/acpx/src/codex-auth-bridge.test.ts → 12 tests, 10 pass, 2 unrelated pre-existing failures (the bundled-dep tests).
2. Apply this PR: pnpm vitest run extensions/acpx/src/codex-auth-bridge.test.ts → 18 tests, 16 pass, same 2 unrelated pre-existing failures.

Expected

• prepareAcpxCodexAuthConfig returns a resolved config and writes both wrapper files when fs.chmod rejects with any of EPERM / EACCES / EROFS / ENOSYS / ENOTSUP.
• prepareAcpxCodexAuthConfig propagates unexpected errnos (e.g. ENOSPC) so genuine bugs stay visible.

Actual

• Before: EPERM from fs.chmod aborts prepareAcpxCodexAuthConfig → acpx-runtime plugin fails to start.
• After: EPERM is swallowed at the chmod site only; everything else continues normally.

Evidence

• Failing test/log before + passing after

$ pnpm vitest run extensions/acpx/src/codex-auth-bridge.test.ts
…
 ✓ tolerates fs.chmod failing with EPERM on the wrapper script (regression #73333)
 ✓ tolerates fs.chmod failing with EACCES on the wrapper script (regression #73333)
 ✓ tolerates fs.chmod failing with EROFS on the wrapper script (regression #73333)
 ✓ tolerates fs.chmod failing with ENOSYS on the wrapper script (regression #73333)
 ✓ tolerates fs.chmod failing with ENOTSUP on the wrapper script (regression #73333)
 ✓ still surfaces unexpected fs.chmod errors so real bugs are not hidden (regression #73333)
…
Test Files  1 failed (1)   <-- 2 unrelated pre-existing failures, also present on origin/main
     Tests  2 failed | 16 passed (18)

Human Verification (required)

• Verified scenarios:
  • Targeted vitest run on extensions/acpx/src/codex-auth-bridge.test.ts before and after the change, confirming the 2 pre-existing failures (uses the bundled Codex/Claude ACP dependency by default when it is installed) exist on origin/main and are unrelated to this fix.
  • Wrapper file content unchanged — fs.readFile(wrapperPath, "utf8") still passes the same wrapper-content assertions.
  • Both Codex and Claude wrapper paths exercised by the new tests.
• Edge cases checked: each of the 5 ignored errnos individually; one rethrown errno (ENOSPC).
• What I did not verify: Live reproduction on an actual NFS/SMB mount — the unit test mocks fs.chmod directly because that is the only seam where the kernel would have raised the error.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No
• If yes, exact upgrade steps: N/A.

Risks and Mitigations

• Risk: A future change makes the wrapper file actually-executable-required (e.g., shebang launch). Then a missing +x would silently fail.
  • Mitigation: The helper only swallows the 5 documented errnos; any real launch failure surfaces at spawn time (spawn ENOENT / EACCES) with a clear stack. Today the wrapper is invoked via process.execPath (Node), enforced by tests.

Changed files

• extensions/acpx/src/codex-auth-bridge.test.ts (modified, +70/-1)
• extensions/acpx/src/codex-auth-bridge.ts (modified, +33/-2)

PR #415: fix(openclaw): roll back to 2026.4.22 fat — escape v4.25 NFS+SQLite hang

• Repository: Isol8AI/isol8
• Author: prez2307
• State: closed | merged: True
• Link: https://github.com/Isol8AI/isol8/pull/415

Description (problem / solution / changelog)

Summary

• Pin openclaw-version.json to alpine/openclaw:2026.4.22 (fat variant). Drops -slim.
• Add three schema-required fields to agents.defaults (embeddedHarness, contextLimits, heartbeat) — required by v2026.4.22 zod schema.
• Re-enable channel plugins (telegram, discord, slack → enabled: true); the disable was a v4.25-specific defensive patch.

Why

v2026.4.25-slim deterministically wedges every container start. From a live ECS-exec probe on the running gateway:

PID 52 (openclaw-gateway):
  State: D (uninterruptible disk sleep)
  wchan: rpc_wait_bit_killable
  fds:   /home/node/.openclaw/tasks/runs.sqlite{,-wal,-shm}
  mount: 127.0.0.1:/  /home/node/.openclaw  nfs4  hard,port=21005

Matches upstream issue #73517 — task-registry hot-loop on stale runs.sqlite (reported against the same commit aa36ee6). Loopback NFS server inside the openclaw container deadlocks the gateway's main JS thread.

Forward path is blocked too: v2026.4.26 has an unfixed acpx-EPERM regression on remote filesystems (#73333, fix PR #73341 closed but not merged).

So the only safe move is back. We previously ran on 2026.4.22 fat in #406 with no hang. Fat variant has all bundled plugin runtime deps prebaked → no 90s install penalty on first boot. Has CODEX_HOME (added 4.7) so ChatGPT OAuth works.

Test plan

• CI builds extended image off 2026.4.22 upstream
• Dev redeploys cleanly
• Provision a fresh container, watch CloudWatch logs reach [gateway] ready and stay healthy past starting channels and sidecars... (the wedge point)
• Backend gateway connection pool establishes WS handshake (no more [ws] closed before connect code=1006)
• ChatGPT-OAuth signup path completes end-to-end

Risk

• New tag 2026.4.22-bootstrap won't resolve until the extended-image CI workflow runs once and pushes a per-commit tag. First deploy after merge will fail; subsequent deploys after the image build are fine.

🤖 Generated with Claude Code

Changed files

• apps/backend/core/containers/config.py (modified, +17/-25)
• openclaw-version.json (modified, +5/-5)