sandbox-exec nesting fails when host tool (e.g. Claude Code) also uses sandbox-exec

[umiyosh]

Problem

When a process launched via cage (outer sandbox) spawns child commands that are also wrapped in sandbox-exec (inner sandbox), the inner sandbox fails with:

sandbox-exec: sandbox_apply: Operation not permitted

Exit code 71. Every Bash command fails regardless of path.

Reproduction

1. Launch an application via cage auto-presets (e.g. claude → base + git-enabled + claude-code)
2. The application internally uses sandbox-exec for its own command sandboxing (Claude Code's Bash tool)
3. Inner sandbox-exec call fails because macOS does not support nesting sandbox-exec

Root cause

main.go:129 sets IN_CAGE=1 but never checks it. There is no mechanism to detect or prevent sandbox nesting.

// main.go:128-132
func main() {
	// Indicate that we are running inside a cage
	if err := os.Setenv(inCageEnv, "1"); err != nil { ... }

sandbox_darwin.go:34 unconditionally applies sandbox-exec:

return syscall.Exec(sandboxPath, args, os.Environ())

Affected code paths

• sandbox_darwin.go:16 runInSandbox() — generates and applies profile without nesting check
• main.go:127 main() — sets IN_CAGE env var but doesn't check it on entry

Proposed solution

Add nest detection: if IN_CAGE=1 is already set when cage starts, skip sandbox-exec and directly exec the command.

func main() {
	// Detect nesting — if already inside cage, exec directly
	if os.Getenv(inCageEnv) == "1" {
		cmd := args[0]
		cmdPath, err := exec.LookPath(cmd)
		if err != nil { ... }
		syscall.Exec(cmdPath, args, os.Environ())
		return
	}

	// Normal cage flow...
	os.Setenv(inCageEnv, "1")
	...
}

Alternative or complementary approaches:

• Add a --skip-if-nested flag
• Add a config option nest-behavior: skip | error | warn
• Document that applications with their own sandbox-exec (Claude Code, etc.) should not be auto-preset targets

Environment

• macOS Sequoia (Darwin 24.6.0)
• cage built from main branch (commit 9105203)
• Host tool: Claude Code (uses sandbox-exec internally for Bash command sandboxing)

[umiyosh]

Fork での対応報告 (umiyosh/cage)

この Issue の問題を umiyosh/cage フォークで対処したので、アプローチを共有します。

問題の整理

sandbox-exec のネストは 2 つのレイヤーで発生する:

1. cage-inside-cage: cage cage echo hello のようなケース
2. other-sandbox-inside-cage: cage でラップしたアプリ（Claude Code 等）が内部で独自に sandbox-exec を呼ぶケース

Issue で提案されている IN_CAGE チェックは (1) を解決するが、(2) は解決しない。Claude Code は cage を経由せず直接 sandbox-exec を呼ぶため、IN_CAGE チェックが効かない。

実装したアプローチ（3 層）

Layer 1: IN_CAGE ネスト検出 (main.go)

func main() {
    if os.Getenv(inCageEnv) == "1" {
        // Skip flag parsing, extract command, exec directly
        args := skipFlags(os.Args[1:])
        path, _ := exec.LookPath(args[0])
        syscall.Exec(path, args, os.Environ())
    }
    os.Setenv(inCageEnv, "1")
    // ... normal flow
}

→ cage-inside-cage を解決。

Layer 2: canApplySandbox() プローブ (sandbox_darwin.go)

func canApplySandbox() bool {
    cmd := exec.Command("sandbox-exec", "-p", "(version 1)(allow default)", "/usr/bin/true")
    return cmd.Run() == nil
}

runInSandbox() の先頭で呼び、sandbox-exec が適用不可なら sandbox なしで直接 exec にフォールバック。

→ 汎用的なネスト検出（cage 以外の sandbox 内で cage が呼ばれた場合も対応）。

Layer 3: sandbox-exec シム（cage 外・ユーザー側の対処）

#!/bin/sh
# PATH 上で /usr/bin/sandbox-exec より先に配置
if [ "$IN_CAGE" = "1" ]; then
    while [ $# -gt 0 ]; do
        case "$1" in
            -f|-n|-p|-D) shift 2 ;;
            --) shift; break ;;
            *) break ;;
        esac
    done
    exec "$@"
fi
exec /usr/bin/sandbox-exec "$@"

→ cage がラップしたアプリ（Claude Code 等）が直接呼ぶ sandbox-exec をインターセプト。IN_CAGE=1 のときだけバイパスし、cage なしの通常起動時は本物の sandbox-exec に委譲。

結果

シナリオ	動作
cage cage echo hello	Layer 1 で内側の cage がスキップ
cage claude → Claude Code Bash tool	Layer 3 のシムが sandbox-exec をバイパス
claude（cage なし）	シムが本物の sandbox-exec に委譲、通常通り sandbox 有効
任意の sandbox 内で cage echo hello	Layer 2 で sandbox-exec 不可を検出しフォールバック

備考

• Layer 3 はユーザー環境側の対処（PATH に shim を配置）であり、cage 本体には含まれない
• cage 本体で対処できるのは Layer 1 + Layer 2 まで
• macOS が sandbox-exec のネストをカーネルレベルで禁止している以上、cage の外で sandbox-exec を呼ぶアプリに対しては cage 単体では完全に解決できない