Implements all three follow-up phases for sandbox environment support: **Phase 1 (bd-9nw): Documentation** ✅ - Comprehensive sandbox troubleshooting section in TROUBLESHOOTING.md - Detailed symptoms, root causes, and escape hatches - Step-by-step troubleshooting workflow - Comparison table for --sandbox, --force, and --allow-stale flags - Global flags section added to CLI_REFERENCE.md - Documents --sandbox, --allow-stale, and --force flags - Usage examples and when to use each flag - GitHub issue #353 comment with immediate workarounds **Phase 2 (bd-u3t): Sandbox Auto-Detection** ✅ - Automatic sandbox detection using syscall.Kill permission checks - cmd/bd/sandbox_unix.go: Unix/Linux/macOS implementation - cmd/bd/sandbox_windows.go: Windows stub (conservative approach) - cmd/bd/sandbox_test.go: Comprehensive test coverage - Auto-enables sandbox mode when detected - Shows: "ℹ️ Sandbox detected, using direct mode" - Respects explicit --sandbox or --no-daemon flags - Updated documentation to reflect auto-detection (v0.21.1+) **Phase 3 (bd-e0o): Enhanced Daemon Robustness** ✅ - Permission-aware process checks in cmd/bd/daemon_unix.go - Correctly handles EPERM (operation not permitted) from syscall.Kill - Treats EPERM as "process exists but not signable" = running - Prevents false negatives in sandboxed environments - Metadata health check in cmd/bd/daemon_event_loop.go - Periodic verification that metadata is accessible - Helps detect external import operations (bd import --force) - Non-fatal logging for diagnostics - Comprehensive test suite in cmd/bd/daemon_unix_test.go - Self-check, init process, nonexistent process, parent process tests **Impact:** - Codex users: No manual intervention needed, auto-detected - Stuck states: Three escape hatches (--sandbox, --force, --allow-stale) - Daemon robustness: Handles permission-restricted environments gracefully - All three follow-up issues (bd-9nw, bd-u3t, bd-e0o) closed **Files changed:** - cmd/bd/main.go: Auto-detection logic in PersistentPreRun - cmd/bd/sandbox_unix.go: Unix sandbox detection (new) - cmd/bd/sandbox_windows.go: Windows sandbox detection stub (new) - cmd/bd/sandbox_test.go: Sandbox detection tests (new) - cmd/bd/daemon_unix.go: Permission-aware isProcessRunning() - cmd/bd/daemon_unix_test.go: Process check tests (new) - cmd/bd/daemon_event_loop.go: Metadata health check - docs/TROUBLESHOOTING.md: Comprehensive sandbox section - docs/CLI_REFERENCE.md: Global flags documentation Closes bd-9nw, bd-u3t, bd-e0o Related: GH #353 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
41 lines
1.2 KiB
Go
41 lines
1.2 KiB
Go
//go:build unix
|
|
|
|
package main
|
|
|
|
import (
|
|
"os"
|
|
"syscall"
|
|
)
|
|
|
|
// isSandboxed detects if we're running in a sandboxed environment where process signaling is restricted.
|
|
//
|
|
// Detection strategy:
|
|
// 1. Check if we can send signal 0 (existence check) to our own process
|
|
// 2. If we get EPERM (operation not permitted), we're likely sandboxed
|
|
//
|
|
// This works because:
|
|
// - Normal environments: processes can signal themselves
|
|
// - Sandboxed environments (Codex, containers): signal operations restricted by MAC/seccomp
|
|
//
|
|
// False positives are rare because:
|
|
// - Normal users can always signal their own processes
|
|
// - EPERM only occurs when OS-level security policies block the syscall
|
|
//
|
|
// Implements bd-u3t: Phase 2 auto-detection for GH #353
|
|
func isSandboxed() bool {
|
|
// Try to send signal 0 (existence check) to our own process
|
|
// Signal 0 doesn't actually send a signal, just checks permissions
|
|
pid := os.Getpid()
|
|
err := syscall.Kill(pid, 0)
|
|
|
|
if err == syscall.EPERM {
|
|
// EPERM = Operation not permitted
|
|
// We can't signal our own process, likely sandboxed
|
|
return true
|
|
}
|
|
|
|
// No error or different error = not sandboxed
|
|
// Different errors (ESRCH = no such process) shouldn't happen for our own PID
|
|
return false
|
|
}
|