[Bug]: ocx claude --dangerously-skip-permissions aborts as root (uid==0) because IS_SANDBOX is never set

[rrmlima]

Summary

ocx claude --dangerously-skip-permissions aborts immediately when running as root (uid == 0), which is the default on most VPS deployments. Claude Code 2.1.205+ embeds a safety guard that exits with --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons unless it believes it runs inside a sandbox (IS_SANDBOX=1) or a bubblewrap wrapper is present. The opencodex proxy launches the session, so it should mark the environment accordingly.

Reproduction

# As root (typical VPS):
ocx claude --dangerously-skip-permissions --print "ok"

Expected: the Claude session starts and prints ok.
Actual: immediate fatal exit with the root-guard message.

Logs and screenshots

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

Area

CLI

Version

2.14.2 (also on current main — IS_SANDBOX does not appear anywhere in src/)

OS

Ubuntu 24.04 (root user)

Config shape

N/A (CLI invocation only)

Root cause

src/cli/claude.ts buildClaudeEnv does not set IS_SANDBOX. The guard is in the official Claude Code binary, not in opencodex — but since the proxy owns the launched session (a controlled, proxy-launched environment), it must signal IS_SANDBOX=1 so the binary allows the bypass. Without it, every root-hosted deployment of ocx claude with permissions bypass is unusable.

Proposed fix

In buildClaudeEnv, before return env;:

   for (const [name, value] of Object.entries(effectiveModelEnv(config.claudeCode, contextWindows, auto))) {
     setDefault(name, value);
   }
+  // Root bypass guard (Claude Code 2.1.205+): the CLI refuses --dangerously-skip-permissions
+  // when uid==0 unless it believes it runs inside a sandbox. Servers are commonly root, so
+  // treat the proxy-launched session as one — opt out by exporting IS_SANDBOX=0 yourself.
+  if (typeof process.getuid === "function" && process.getuid() === 0) {
+    setDefault("IS_SANDBOX", "1");
+  }
   return env;

setDefault semantics already guarantee the user can override (IS_SANDBOX=0 exported by the user wins), so this is an opt-out-by-env design, not a forced change.

Alternatives considered

• Document "run as non-root": impractical on VPS setups where the service owns root files, and Claude Code already provides the sandbox escape hatch (IS_SANDBOX) for exactly this case.
• Require CLAUDE_CODE_BUBBLEWRAP: heavier, not portable; IS_SANDBOX is the documented, minimal signal.

Additional context

The same pattern is used by other proxy-launcher tools: the session is a controlled environment created by the parent process, so marking it as sandboxed for the child's safety guard is accurate and safe. The user opt-out (IS_SANDBOX=0) preserves the strict behavior for anyone who wants it.

Test matrix:

• root + --dangerously-skip-permissions → session starts (200 / prints)
• root + exported IS_SANDBOX=0 → original guard behavior preserved (user opted out)
• non-root → unchanged (no IS_SANDBOX injected)

[coderabbitai]

🔗 Related PRs

#573 - fix(server): treat forwarded loopback ports as loopback [merged]
#936 - fix: harden credential and runtime trust boundaries (rebase of #916) [merged]
#1358 - fix(claude): contain main credentials to canonical forward routes [merged]
#1360 - fix(claude): bind proxy admission tokens to local destinations [merged]
#1441 - fix(codex): stop recursive dynamic-launcher shims [open]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[Wibias]

The workflow problem here is real, but #1701 is being closed because uid == 0 is not sandbox evidence. OpenCodex launching Claude as a child process does not itself create an OS security boundary, so automatically setting IS_SANDBOX=1 would claim isolation that does not exist and can suppress Claude Code's root guard while --dangerously-skip-permissions is active.

Preferred solution: create a real sandboxed launch path

If OpenCodex wants to support ocx claude --dangerously-skip-permissions as root, the clean solution is to make the sandbox claim true rather than bypass the check.

Conceptually:

root launch
  -> establish real OS-level sandbox/isolation
  -> verify sandbox setup succeeded
  -> set IS_SANDBOX=1 for the child
  -> launch Claude Code

On Linux this should use an actual isolation primitive suitable for the project, for example a bubblewrap-based launch path or another reviewed sandbox mechanism. The exact implementation needs a threat-modelled contract for filesystem access, process access, network access, required mounts, working directory access, and any capabilities that must remain available for normal Claude Code operation.

Important requirements:

• Never derive IS_SANDBOX=1 from UID alone.
• Set it only after the isolation mechanism has positively succeeded.
• If sandbox creation or verification fails, fail closed and keep Claude Code's normal root protection intact. Do not silently fall back to an unsandboxed root launch with the flag set.
• Preserve explicit user-provided sandbox-related environment where appropriate, but do not manufacture a sandbox claim merely because OpenCodex owns the launcher.
• Add integration coverage that proves the child is actually launched through the isolation path, not only a unit test that checks the environment variable.
• Keep non-root ocx claude behaviour unchanged.

A smaller explicit unsafe opt-in could technically work as an escape hatch, but it still intentionally defeats an upstream safety guard. A real sandboxed launcher is the preferred long-term fix because it solves the original VPS/root workflow without weakening the meaning of IS_SANDBOX.

[yzxcj797]

Implementing with one deliberate deviation from the proposed diff: IS_SANDBOX=1 is set only when the user explicitly passed --dangerously-skip-permissions (detected in cmdClaude and threaded through ClaudeEnvDeps), not for every launch. Rationale: the variable exists to relax a vendor safety guard, and marking every proxy-owned session as sandboxed could silence other guard behaviors in future Claude Code versions; an ordinary ocx claude launch keeps the vendor's default posture. An explicit user export still wins (setDefault semantics).

Tests cover the bypass launch setting it, the ordinary launch not setting it, and the user-export-wins case.