2026 OpenClaw sessions_spawn·샌드박스 세션 문제: 권한·경로·Mac 클라우드에서 재현 가능한 진단
게이트웨이는 동작하지만 자식 프로세스·샌드박스에서만 실패할 때는 작업 디렉터리·프로세스 사용자·파일 권한·샌드박스 정책을 우선 의심합니다. 첫 배포, 공통 오류, 프로덕션 하드닝과 함께 읽으면 분기가 빨라집니다.
1. 세 가지 패턴: 게이트웨이가 떠 있다고 spawn이 성공하는 것은 아니다
첫 배포와 공통 오류까지 끝난 뒤 가장 헷갈리는 것은 「프로세스는 살아 있는데 세션 생성·샌드박스 내부 명령만 실패한다」는 패턴입니다. 로그에 sessions_spawn 또는 샌드박스 관련 키워드가 보이면 포트 18789 리스닝과는 다른 경로입니다. 프로덕션 하드닝 문서와 함께 보면 정책과 경로를 한 표에 정리하기 쉽습니다.
- cwd·설정 경로 불일치: 대화형 SSH는
~/project인데 launchd로 올린 게이트웨이는/또는 다른 사용자 홈에서 시작한다. 자식 프로세스는 비어 있거나 쓸 수 없는 cwd를 물려받아 spawn 단계에서 실패한다. APFS는 기본적으로 대소문자를 구분하지 않아 Linux에서 온 경로를 잘못 복사하면 간헐적 실패로 보인다. - UID·파일 소유자 불일치:
openclaw.json편집 후 프로세스 사용자와 캐시·저장소 소유자가 어긋나면 샌드박스 안에서 쓰기·실행이 거절된다. 수동gateway start와 launchd는 실제 사용자가 다를 수 있어 「가끔」처럼 보인다. - 샌드박스 정책과 채널 능력 불일치: 출구 제한·자식 프로세스 제한·작업 집합 제한을 죄이면 정당한 자동화도 막힌다. 게이트웨이 로그가 spawn error만 던지면 앱 버그로 오인하기 쉬우나 실제로는 정책 조합인 경우가 많다.
벤치마크로 콜드 부트 후 launchd만으로 게이트웨이를 올렸을 때 첫 spawn 성공까지의 시간을 재면 좋다. SSH로 들어가면 고쳐진다면 입구나 환경 변수 상속이 깨진 것이다.
2. 분기 표: 세션·게이트웨이·포트
인증·포트·샌드박스를 동시에 손대면 어느 층이 효과였는지 알 수 없다. 「보통 아님」 열로 초기 오진을 줄인다.
| 관찰 | 우선 의심 | 확인 | 보통 아님 |
|---|---|---|---|
doctor 성공, 작업에서 spawn·session 오류 | 세션·샌드박스·경로 | 동일 사용자로 최소 명령 재현, cwd와 설정 경로 대조 | 단순 18789 점유(listen 전에 죽지 않은 경우) |
| 클라이언트 Unauthorized·토큰 | 게이트웨이 인증 | openclaw config get 계열로 gateway.auth와 문서 대조 | 디렉터리 chmod(토큰 파일을 못 읽는 경우 제외) |
| 게이트웨이가 안 뜨거나 즉시 종료 | 포트·환경·의존성 | lsof -i :18789, 메모리, Node 버전 | 샌드박스 비즈니스 로직(세션 층에 미도달) |
| 특정 유형 작업만 실패 | 정책 또는 경로 허용 | 일시 완화 후 비교, 하드닝 문서 참고 | 채널 플러그인 단독(OS 층을 먼저 제거) |
| 업그레이드 직후 변화 | 설정 키 이전·기본 강화 | 릴리스 노트와 구 OPENCLAW_* 대조표 | 무작위 불안정(대개 설정 드리프트) |
3. 재현 가능한 진단(5+회귀)
프로덕션과 동일한 Unix 사용자로 게이트웨이를 실행한다는 전제다. SSH 사용자와 launchd 사용자가 다르면 먼저 맞춘다.
- 시작 입구 고정: launchd·수동·감독 프로세스 중 무엇인지 문서화. 전환 전
openclaw gateway stop과lsof -i :18789로 이중 인스턴스 제거. - 최소 재현: 프로덕션과 같은
cwd에서 문서의 최소 세션·작업만 실행. SSH에서는 되고 launchd에서는 안 되면 환경 상속 문제다. - 권한·소유자: 오류 경로에
ls -le(macOS에서 ACL 중요). 필요 시 단일 소유자로 상태 디렉터리를 재생성하고 uid/gid를 Runbook에 기록. - 로그 분리: OpenClaw 로그와 통합 로그(아래 예)의 거부를 따로 본다.
- 설정 diff: 업그레이드·머지 후
openclaw.json을 구조화 diff하고 샌드박스·경로·env 블록을 집중 확인. - 회귀:
doctor→최소 세션→실제 작업→24시간 cron류 트리거.
WorkingDirectory가 있는지 확인하라. 없으면 자식 cwd가 비어 spawn이 조용히 실패한다.Mac 클라우드 장기 운영에서는 「입구+cwd+소유자」를 CI와 같은 수준으로 Runbook에 남긴다.
4. 측정 가능한 기술 정보
① 프로세스 정체성: launchd 환경은 로그인 셸보다 작아 PATH에 Homebrew가 빠져 「바이너리는 보이는데 쓰기는 안 된다」가 발생한다. ② APFS: 대소문자·Linux 동기화 경로 중복. ③ 메모리: 초기화 시 RSS 스파이크로 2GB 미만 인스턴스는 OOM(종료 코드 137)이 spawn 실패로 보인다. ④ 동시성: 동일 상태 디렉터리를 두 게이트웨이가 쓰면 세션 오류처럼 보이는 경쟁이 난다. ⑤ 감사: 샌드박스를 죄일 때마다 한 줄 변경 로그를 남겨 롤백을 증적화한다.
5. 컨테이너에서 네이티브 macOS 세션 기반으로
도커·원격 Linux는 볼륨 권한·신호 전달 차이로 스택이 두 겹이 된다. 노트북 상시 실행은 수면·VPN·홈 경로 변화로 재현성이 무너진다. 범용 Linux VPS 런북은 웹 중심이라 launchd+소유자 전제의 spawn 진단은 흔히 얇다.
네이티브 macOS 동작·안정 UID·쓰기 가능한 상태 디렉터리·7×24가 필요하면 전용 Mac 클라우드가 레이어를 줄인다. VPSMAC M4 Mac 클라우드를 임대해 launchd로 사용자와 WorkingDirectory를 고정하고 샌드박스·게이트웨이 설정을 같은 저장소로 관리하면 spawn·세션 문제를 단일 OS 의미 안에 가둘 수 있다.
6. FAQ
spawn만 실패하고 게이트웨이는 살아 있다
먼저 cwd·사용자·소유자. 프로덕션과 같은 시작 경로에서 pwd를 찍고 plist의 WorkingDirectory와 맞춘다. 최소 spawn 예제를 동일 사용자로 실행하고 SSH와 launchd의 env 차이를 비교한다.
업그레이드 직후에만 깨진다
키 이름·기본 샌드박스·블록 이동이 흔한 원인이다. openclaw.json diff와 릴리스 노트의 OPENCLAW_* 표를 맞추고 하드닝 문서의 정책 블록과 대조한다.
한 호스트에 여러 인스턴스
상태 디렉터리를 공유하지 말 것. 설정 루트·포트·호스트를 분리한다. 조용한 이중 기동은 레이스 같은 세션 오류의 대표 원인이다.