32. OpenClaw browser에서 Access denied가 뜰 때 해결

OpenClaw browser를 쓰다가 {"error":"blocked","message":"Access denied."}가 뜨면, 많은 사람이 바로 브라우저 자체가 죽었다고 생각한다. 그런데 실제 운영에서는 이 메시지가 브라우저 프로세스 고장보다 지금 쓰려는 프로필 경로가 현재 환경에서 허용되지 않거나, attach 승인이 아직 안 끝난 상태에서 더 자주 보인다.

공식 browser CLI 문서와 Browser tool 문서를 같이 보면 기준선은 꽤 명확하다. 기본값인 openclaw 프로필은 OpenClaw가 관리하는 격리된 전용 브라우저이고, user 프로필은 실제 로그인된 사용자 브라우저에 붙는 경로다. 즉, 같은 브라우저 제어라도 성격이 다르다. 이 차이를 무시하면 “왜 어떤 작업은 되는데 어떤 작업은 Access denied지?”가 반복된다.

특히 공식 문서는 user 프로필을 쓸 때 기존 로그인 세션이 꼭 필요하고, 사용자가 컴퓨터 앞에서 attach prompt를 직접 승인할 수 있을 때를 권장한다. 반대로 일반 자동화는 기본적으로 openclaw 프로필을 권장한다. 그래서 이 오류는 브라우저를 더 세게 재시작하기보다, 먼저 어떤 프로필을 타고 있는지부터 확인하는 편이 훨씬 빠르다.

flowchart TD
A[Browser 작업 실행] --> B{Access denied 발생?}
B -->|아니오| C[정상 진행]
B -->|예| D{지금 profile이 무엇인가?}
D -->|openclaw| E[start/status/tabs 재확인]
D -->|user| F[attach prompt 승인 가능 여부 확인]
F -->|불가| G[openclaw 프로필로 전환]
F -->|가능| H[user profile 재시도]
E --> I{원격 gateway인가?}
H --> I
I -->|예| J[node host / remote browser 경로 확인]
I -->|아니오| K[snapshot/tabs로 재검증]
J --> K

칠판 치트시트

Access denied는 브라우저 고장보다 프로필/attach 경로 불일치일 때 더 자주 보인다

일반 자동화는 openclaw 프로필이 기본이다

기존 로그인 세션이 꼭 필요할 때만 user 프로필을 쓴다

user 프로필은 사용자가 실제로 attach prompt를 승인할 수 있어야 한다

원격 gateway에서는 existing-session/user보다 node host 또는 remote browser 경로를 먼저 본다

이런 증상이면 이 문서가 바로 맞다

browser 작업 자체는 호출됐는데 바로 Access denied가 떨어진다.
같은 사이트라도 openclaw 프로필에서는 되는데 user 경로에서는 막힌다.
heartbeat/cron 같은 무인 작업에서 브라우저 확인을 붙이려 할 때 차단된다.
로그인 세션이 필요한 페이지를 자동화하려다가 갑자기 막힌다.
로컬에서는 될 것 같은데 remote gateway/헤드리스 환경에서는 브라우저 접근이 계속 거부된다.

왜 이런 일이 생기는가

1) `openclaw`와 `user`는 같은 브라우저가 아니다

공식 Browser tool 문서는 openclaw를 OpenClaw가 관리하는 격리 브라우저, user를 실제 로그인된 사용자 브라우저에 붙는 built-in Chrome MCP attach profile로 설명한다. 즉 둘은 이름만 다른 옵션이 아니라, 애초에 접근 방식이 다르다.

이 차이를 놓치면 이런 착시가 생긴다.

“browser tool은 켜져 있는데 왜 이 작업만 막히지?”
“openclaw 프로필은 되는데 user 프로필만 안 되네?”
“브라우저가 떠 있으니 attach도 자동으로 될 거야”

실제로는 셋 다 같은 문제가 아니다. 첫째는 도구 가용성, 둘째는 프로필 성격 차이, 셋째는 attach 승인 문제다.

2) `user` 프로필은 사람 승인 전제가 붙는다

공식 문서는 user 프로필을 existing logged-in session이 중요하고, 사용자가 컴퓨터 앞에서 attach prompt를 클릭/승인할 수 있을 때 쓰라고 안내한다. 이 말은 거꾸로 읽으면, 사람이 앞에 없거나 attach prompt를 처리할 수 없는 heartbeat/cron/원격 자동화에서는 이 경로가 쉽게 막힐 수 있다는 뜻이다.

즉 Access denied가 떴다고 무조건 권한 시스템 전체가 망가진 게 아니다. 현재 세션이 사람 확인이 필요한 경로를 무인으로 타고 있어서 막힌 것일 수 있다.

3) 원격 gateway에서는 로컬 사용자 브라우저 경로가 더 까다롭다

공식 browser CLI 문서는 existing-session/user 경로를 사실상 host-only로 설명하고, gateway와 브라우저가 다른 머신에 있으면 node host나 remote browser control 경로를 쓰라고 안내한다. 관련 원격 구조는 remote 문서 쪽을 같이 보면 이해가 쉽다.

즉 remote mode에서 내 손에 있는 브라우저 감각만 믿고 user 프로필을 쓰면, 실제 gateway 기준에서는 붙을 수 없는 경로일 수 있다. 이때도 체감상 메시지는 Access denied 한 줄처럼 보여서, 브라우저가 죽은 것처럼 오해하기 쉽다.

가장 빠른 5분 복구 순서

1) 먼저 “지금 어느 프로필을 쓰는지”부터 자른다

가장 먼저 해야 할 질문은 이것이다.

지금 일반 자동화인가?
아니면 기존 로그인 세션이 꼭 필요한가?
현재 profile이 openclaw인가, user인가?

일반 웹 확인, 공개 페이지 열기, 단순 스냅샷 같은 작업이면 공식 기준으로는 openclaw가 기본값이다. 여기서 user를 먼저 고집할 이유가 적다.

실무에서는 이 한 줄로 정리하면 빠르다.

로그인 세션 불필요 → openclaw
기존 로그인 세션 필요 + 사용자 현장 승인 가능 → user

2) 일반 자동화면 `openclaw`로 바로 되돌린다

공식 문서의 quick start도 openclaw browser --browser-profile openclaw start → open → snapshot 순서로 잡혀 있다. 즉 기본 자동화가 목적이라면 user 경로에 매달리지 말고, 먼저 openclaw에서 재현해 보는 편이 맞다.

복구 흐름은 단순하다.

openclaw 프로필 상태를 본다.
필요하면 start를 먼저 한다.
tabs/snapshot이 되는지 본다.
그다음 원래 작업으로 다시 간다.

검증 포인트는 단순해야 한다. 공개 문서 예시처럼 status → tabs → open/snapshot이 통과하면, 브라우저 제어 plane 자체는 살아 있다고 봐도 된다.

3) 로그인 세션이 꼭 필요하면 `user`를 쓰되, attach 조건을 먼저 맞춘다

기존 Gmail, SaaS 관리 콘솔, 로그인된 사내 도구처럼 이미 로그인된 실제 사용자 세션이 필요할 때는 user 경로가 맞다. 하지만 이때는 “브라우저가 켜져 있음”만으로 부족하다. 공식 문서 기준으로는 사용자가 attach prompt를 직접 승인할 수 있어야 한다.

이 단계에서 확인할 것은 세 가지다.

사용자가 실제로 컴퓨터 앞에 있는가
attach prompt를 눌러 줄 수 있는가
지금이 무인 heartbeat/cron처럼 승인 불가능한 시점은 아닌가

여기서 하나라도 안 맞으면, 같은 사이트라도 user 프로필은 계속 막힐 수 있다. 이때는 실패를 길게 끌지 말고 openclaw로 분리 가능한 작업인지 먼저 판단하는 편이 낫다.

4) remote gateway면 브라우저 위치부터 다시 본다

공식 문서는 gateway와 브라우저가 다른 머신이면 node host를 둬서 브라우저 제어를 프록시하게 하거나, remote browser/CDP 경로를 쓰라고 안내한다. 즉 내 노트북 브라우저 감각과 gateway가 실제로 붙는 브라우저 위치가 다를 수 있다.

이때 자주 생기는 실패 흐름은 이렇다.

사람은 로컬 크롬을 보고 있다.
실제 작업은 remote gateway에서 돈다.
그런데 세션은 user/existing-session처럼 호스트 로컬 브라우저 전제를 타고 있다.
결과는 짧게 Access denied 또는 접근 실패처럼 보인다.

그래서 remote 환경에서는 “브라우저가 켜져 있나?”보다 어느 머신의 어떤 프로필에 붙으려는가를 먼저 보는 것이 더 중요하다.

5) 마지막은 짧은 명령으로 재검증한다

이 오류는 긴 자동화 전체를 바로 다시 돌리면 원인이 흐려진다. 먼저 짧은 검증으로 닫는 편이 좋다.

권장 순서는 이렇다.

status
tabs
snapshot 또는 공개 페이지 1개 열기

이 세 단계가 통과한 뒤에만 원래 작업으로 돌아가면, “브라우저 접근 자체는 복구됐는지”를 더 분명하게 구분할 수 있다.

현장 미니 사례 2개

사례 A) heartbeat에서 로그인 페이지 확인을 붙였더니 막힌 경우

상황: 주기 작업에서 브라우저 확인을 붙였는데 Access denied가 떨어짐
실제 원인: 사람이 승인해야 하는 user 경로를 무인 heartbeat에서 사용함
복구: 공개 페이지 확인은 openclaw 프로필로 분리, 로그인 세션이 필요한 작업만 사용자 승인 가능한 시간대로 이동
검증: openclaw에서 status → tabs → snapshot 통과 후 루틴 재개

사례 B) 로컬에선 괜찮아 보이는데 remote gateway에서만 막힌 경우

상황: 브라우저는 눈앞에 떠 있는데 자동화만 계속 접근 거부
실제 원인: gateway와 브라우저가 다른 머신에 있어 user/existing-session 전제가 어긋남
복구: node host 또는 remote browser 경로로 재구성하고, 일반 자동화는 openclaw로 우선 분리
검증: gateway 기준 브라우저 tabs와 open이 먼저 통과하는지 확인

운영자가 바로 판단하는 기준

상황	먼저 볼 것	이유
공개 페이지 자동화인데 `Access denied`	현재 profile	보통 `user`를 불필요하게 타고 있을 가능성이 큼
기존 로그인 세션이 꼭 필요	사용자 현장 승인 가능 여부	`user` 경로는 attach prompt 전제가 붙는다
remote gateway에서만 실패	브라우저 위치/노드 경로	호스트 로컬 브라우저 가정이 틀렸을 수 있음
status/tabs도 안 됨	브라우저 control plane 자체	프로필 이전에 런타임 상태부터 봐야 함
`openclaw`는 되는데 `user`만 안 됨	attach/승인/실행환경	브라우저 전체 장애보다 접근 경로 mismatch 가능성이 큼

검색형 FAQ

Q1. `Access denied`면 브라우저가 죽은 건가요?

꼭 그렇진 않다. 공식 문서 기준으로는 openclaw와 user의 성격이 다르다. 특히 user는 실제 사용자 브라우저 attach 경로라서, 사람이 승인할 수 없는 상황이면 접근이 막힐 수 있다.

Q2. 일반 자동화도 `user` 프로필로 해야 하나요?

아니다. 공식 Browser tool 문서는 기본적으로 격리 브라우저인 openclaw를 기본값으로 둔다. 기존 로그인 세션이 꼭 필요한 경우만 user를 우선 검토하면 된다.

Q3. 왜 heartbeat나 cron에서만 이런 문제가 잘 생기나요?

무인 실행에서는 attach prompt를 처리할 사람이 없기 때문이다. 즉 브라우저 문제보다 승인 경로가 필요한 프로필을 무인 환경에서 쓴 것일 수 있다.

Q4. remote gateway인데 내 로컬 브라우저를 그대로 쓸 수 있나요?

공식 문서 기준으로는 existing-session/user는 host-only 성격이 강하다. gateway와 브라우저가 다른 머신이면 node host 또는 remote browser 경로를 먼저 고려하는 편이 맞다.

Q5. 가장 먼저 확인할 명령은 무엇인가요?

공식 quick start 흐름처럼 status → tabs → open/snapshot 순서로 짧게 자르는 편이 가장 빠르다. 여기서 통과하면 브라우저 제어 자체는 살아 있고, 이후 문제는 profile/attach 쪽으로 좁혀진다.

내부링크·다음글 연결 (10)

다음 추천 읽기: 12. 브라우저 릴레이 연동 구조

한 줄 결론

OpenClaw browser에서 Access denied가 뜰 때는 브라우저를 다시 세게 띄우기보다, 먼저 지금 openclaw 프로필을 써야 하는지, user 프로필을 써야 하는지, 그리고 attach를 처리할 사람이 실제로 있는지부터 자르는 편이 훨씬 빠르다.

※ 이 문서는 생성형 AI를 활용해 작성되었습니다.

일하는 ai

탐색기

32. OpenClaw browser에서 Access denied가 뜰 때 해결

칠판 치트시트

이런 증상이면 이 문서가 바로 맞다

왜 이런 일이 생기는가

1) `openclaw`와 `user`는 같은 브라우저가 아니다

2) `user` 프로필은 사람 승인 전제가 붙는다

3) 원격 gateway에서는 로컬 사용자 브라우저 경로가 더 까다롭다

가장 빠른 5분 복구 순서

1) 먼저 “지금 어느 프로필을 쓰는지”부터 자른다

2) 일반 자동화면 `openclaw`로 바로 되돌린다

3) 로그인 세션이 꼭 필요하면 `user`를 쓰되, attach 조건을 먼저 맞춘다

4) remote gateway면 브라우저 위치부터 다시 본다

5) 마지막은 짧은 명령으로 재검증한다

현장 미니 사례 2개

사례 A) heartbeat에서 로그인 페이지 확인을 붙였더니 막힌 경우

사례 B) 로컬에선 괜찮아 보이는데 remote gateway에서만 막힌 경우

운영자가 바로 판단하는 기준

검색형 FAQ

Q1. `Access denied`면 브라우저가 죽은 건가요?

Q2. 일반 자동화도 `user` 프로필로 해야 하나요?

Q3. 왜 heartbeat나 cron에서만 이런 문제가 잘 생기나요?

Q4. remote gateway인데 내 로컬 브라우저를 그대로 쓸 수 있나요?

Q5. 가장 먼저 확인할 명령은 무엇인가요?

내부링크·다음글 연결 (10)

한 줄 결론

그래프 뷰

목차

백링크

일하는 ai

탐색기

32. OpenClaw browser에서 Access denied가 뜰 때 해결

칠판 치트시트

이런 증상이면 이 문서가 바로 맞다

왜 이런 일이 생기는가

1) openclaw와 user는 같은 브라우저가 아니다

2) user 프로필은 사람 승인 전제가 붙는다

3) 원격 gateway에서는 로컬 사용자 브라우저 경로가 더 까다롭다

가장 빠른 5분 복구 순서

1) 먼저 “지금 어느 프로필을 쓰는지”부터 자른다

2) 일반 자동화면 openclaw로 바로 되돌린다

3) 로그인 세션이 꼭 필요하면 user를 쓰되, attach 조건을 먼저 맞춘다

4) remote gateway면 브라우저 위치부터 다시 본다

5) 마지막은 짧은 명령으로 재검증한다

현장 미니 사례 2개

사례 A) heartbeat에서 로그인 페이지 확인을 붙였더니 막힌 경우

사례 B) 로컬에선 괜찮아 보이는데 remote gateway에서만 막힌 경우

운영자가 바로 판단하는 기준

검색형 FAQ

Q1. Access denied면 브라우저가 죽은 건가요?

Q2. 일반 자동화도 user 프로필로 해야 하나요?

Q3. 왜 heartbeat나 cron에서만 이런 문제가 잘 생기나요?

Q4. remote gateway인데 내 로컬 브라우저를 그대로 쓸 수 있나요?

Q5. 가장 먼저 확인할 명령은 무엇인가요?

내부링크·다음글 연결 (10)

한 줄 결론

그래프 뷰

목차

백링크

1) `openclaw`와 `user`는 같은 브라우저가 아니다

2) `user` 프로필은 사람 승인 전제가 붙는다

2) 일반 자동화면 `openclaw`로 바로 되돌린다

3) 로그인 세션이 꼭 필요하면 `user`를 쓰되, attach 조건을 먼저 맞춘다

Q1. `Access denied`면 브라우저가 죽은 건가요?

Q2. 일반 자동화도 `user` 프로필로 해야 하나요?