Codex 'The browser access host is unavailable' 해결법: 경로별 확인 순서

The browser access host is unavailable는 Codex가 브라우저에 접근하기 전에 거치는 연결 확인에서 실패했다는 뜻입니다. 무엇을 해야 하는지는 Codex를 어디서 실행했는지에 따라 갈립니다.

• 터미널 Codex CLI, codex exec, VS Code·JetBrains 확장, 서드파티 호스트, SSH 프로젝트: OpenAI 문서는 Browser를 Codex CLI와 IDE 확장에서 쓸 수 없다고 적고 있습니다. 2026년 11월 11일 기준 OpenAI 답변도 수정 버전도 없으므로, 로컬 설정을 바꾸기보다 브라우저가 필요한 단계를 같은 컴퓨터의 ChatGPT 데스크톱 앱 대화로 옮기는 편이 빠릅니다.
• ChatGPT 데스크톱 앱 안의 Codex·Work 대화, 또는 @Chrome 같은 브라우저 확장 경로: OpenAI가 안내하는 브라우저 연결 점검 순서(앱 업데이트 → 브라우저 재시작 → Manage 표시 확인 → 새 대화 → 앱 완전 재시작)를 따라갑니다.

여기서 말하는 "Codex 앱"과 "ChatGPT 데스크톱 앱"은 같은 앱입니다. OpenAI 변경 기록은 데스크톱 릴리스를 "Codex app"으로 표기하고, 문서는 "ChatGPT desktop app"이라고 부르며, macOS에서는 ChatGPT.app, Windows에서는 OpenAI.Codex 패키지로 설치됩니다.

오류가 난 곳: CLI·IDE인가, 데스크톱 앱 안인가

같은 오류 문구라도 경로마다 의미가 다릅니다. 아래 표에서 자신의 경우를 먼저 고르세요.

CLI·IDE·호스트 쪽 보고는 거의 모두 "같은 컴퓨터에서 데스크톱 앱으로 시작한 대화는 같은 브라우저를 그대로 쓸 수 있다"고 적고 있습니다(#57641, #58916). 그래서 이 경우에는 Chrome 확장을 다시 설치하거나 브라우저 프로필을 바꿔도 대개 달라지지 않습니다. 확장 점검이 의미가 있는 것은 데스크톱 앱 안에서도 실패할 때입니다.

"The browser access host is unavailable": CLI·IDE는 미지원 경로

OpenAI의 Browser 문서는 첫 줄에서 "Browser isn't available in Codex CLI or the Codex IDE extension. Open the ChatGPT desktop app to use the built-in browser."라고 밝힙니다. 데스크톱 앱 안에서는 Computer Use 기능으로 내장 브라우저(@Browser)를 조작하고, 평소 쓰는 Chrome 등을 쓰려면 브라우저 확장을 설치한 뒤 @Chrome처럼 부릅니다. 터미널이나 IDE는 이 문서가 말하는 사용 위치에 들어 있지 않습니다.

그런데도 CLI에서 @Browser가 한동안 동작했다는 보고가 있습니다. 같은 컴퓨터에 설치된 데스크톱 앱의 브라우저 플러그인을 CLI 세션이 함께 쓰는 방식이었고, 10월 중순부터 이 경로가 막혔습니다. 가장 많은 사용자가 모인 #57641은 Windows 11에서 데스크톱 앱을 26.1023.6123.0으로 업데이트한 뒤 터미널 CLI의 @Browser가 실패했다는 내용이고, 2026년 11월 11일 기준 반응 34개와 댓글 50개가 달렸습니다. 확인된 가장 이른 사례는 10월 19일의 #55173입니다.

막히는 지점: 데스크톱 앱이 띄운 프로세스만 받는 환경 변수

macOS에 설치된 브라우저 플러그인(26.1103.60933)의 실행 설정 파일을 보면, 브라우저 제어용 프로세스(cua_repl)에 다음 세 환경 변수를 넘기도록 되어 있습니다.

• BROWSER_USE_ACCESS_EXECUTOR_ID
• BROWSER_USE_ACCESS_PIPE_PATH
• BROWSER_USE_ACCESS_VERIFYING_IDENTITY

#58916의 codex doctor --json 결과를 비롯해 사용자들이 분석한 바로는, 이 중 파이프 경로와 확인용 신원 값은 데스크톱 앱이 직접 띄운 프로세스에만 들어 있습니다. 터미널이나 IDE에서 시작한 세션은 이 값이 없어 브라우저에 닿기 전 접근 확인에서 떨어진다는 설명입니다. OpenAI가 내놓은 설명이 아니라 사용자 분석이지만, "데스크톱 대화는 되고 CLI만 안 된다"는 보고 양상과 맞습니다.

2026년 11월 11일 직접 재현: 데스크톱 26.1103.60933, CLI 0.166.0

2026년 11월 11일 한국 시간 13시 30분, 다음 환경에서 같은 오류를 재현했습니다.

결과는 다음과 같았습니다.

{"browsers":[],"errors":["Browsers: Error: The browser access host is unavailable"]}

데스크톱 앱이 켜져 있고 최신 빌드여도 CLI 쪽 경로는 복구되지 않는다는 뜻입니다. 같은 Mac의 데스크톱 대화 동작과 CLI 0.167.x는 이 재현에 포함하지 않았습니다.

효과가 없었다고 보고된 조치

다음 조치는 CLI·IDE 경로에서 효과가 없었다고 보고됐습니다(#57641, #56928). 시간을 아끼려면 건너뛰어도 됩니다.

• CLI를 0.164.0으로 되돌리기
• 데스크톱 앱과 CLI 재설치, 컴퓨터 재부팅
• codex --no-daemon으로 실행, env_vars 설정 덮어쓰기
• Chrome과 Codex 업데이트, 브라우저 제어 런타임(CUA REPL) 초기화
• 데스크톱 앱을 켜 둔 채 CLI에서 다시 시도
• VS Code에서 만든 대화를 데스크톱 앱에서 열기, 모델 바꾸기

CLI·IDE에서 오류가 났을 때 확인 순서

1. 어느 경로인지 확정합니다. 오류가 터미널, codex exec, IDE 확장, 서드파티 호스트, SSH 세션 중 하나에서 났다면 이 갈래입니다. 데스크톱 앱 창 안의 대화에서 났다면 다음 장으로 넘어가세요.
2. 버전을 적어 둡니다. codex --version과 데스크톱 앱 버전을 메모해 두면, 나중에 수정이 나왔는지 비교하거나 신고할 때 그대로 쓸 수 있습니다(위치는 아래 "신고할 때" 장 참고).
3. 같은 컴퓨터에서 ChatGPT 데스크톱 앱을 열고 새 Codex 또는 Work 대화를 시작합니다. 그 대화에서 @Browser(내장 브라우저)나 @Chrome(확장을 설치한 브라우저)으로 브라우저 작업을 실행합니다. 공식 문서가 안내하는 사용 위치이고, CLI·IDE 보고 대부분에서도 이 대화는 정상 동작했습니다.
4. 브라우저 결과만 터미널 작업으로 가져옵니다. 확인한 화면 내용이나 수집한 데이터를 파일이나 메모로 남기고, 코드 수정은 원래 쓰던 CLI·IDE에서 이어가면 됩니다.
5. SSH·원격 프로젝트라면 브라우저는 로컬 컴퓨터의 데스크톱 앱에서 엽니다. 원격 서버 쪽에서 브라우저 접근을 살리는 공식 방법은 문서에 없습니다.

CLI에서 꼭 브라우저를 써야 할 때: 별도 브라우저 도구

Codex 자체 브라우저 도구가 실패하는 동안 별도의 MCP 도구로 브라우저를 다룬 사용자 보고도 있습니다. Playwright MCP는 VS Code Codex 확장과 CLI 0.166.0에서 동작했고(#58916), Chrome DevTools MCP 1.12.0을 --autoConnect로 붙여 CLI 0.166.0에서 탭 목록을 읽은 사례가 #56928에 있습니다.

이 도구들은 ChatGPT 브라우저 확장을 거치지 않으므로 ChatGPT의 사이트별 허용·차단 목록도 적용되지 않고, 각 도구의 권한 설정을 따로 관리해야 합니다. 특히 로그인된 평소 브라우저 프로필에 연결하면 그 프로필의 세션과 쿠키가 에이전트에게 그대로 노출된다는 점을 감안하세요.

비공식 우회법을 권하지 않는 이유: 접근 확인을 건너뜁니다

#57641에는 CLI에서 다시 브라우저를 쓰게 했다는 사용자 우회법이 몇 가지 올라와 있습니다. 브라우저 제어 프로세스의 실행 설정을 config.toml에서 덮어쓰는 방법, 플러그인의 접근 확인 사전 로드 파일을 고치는 방법, Chrome 플러그인 런타임을 직접 호출하는 방법, 서드파티 브리지 저장소가 그것입니다.

공통점은 데스크톱 앱이 하는 브라우저 접근 확인을 건너뛰거나 돌아간다는 것입니다. OpenAI가 인정한 방법이 아니고, 대가도 분명합니다.

• 로그인된 브라우저를 제어하는 권한 경계가 사라집니다.
• config.toml 덮어쓰기는 데스크톱 앱이 실행될 때마다 지워진다는 보고가 있습니다.
• 다음 플러그인 업데이트에서 파일 구조가 바뀌면 그대로 깨집니다. 실제로 플러그인 실행 설정의 구성은 26.1027과 26.1103 사이에도 바뀌었습니다.

데스크톱 앱 대화에서 @Browser가 실패할 때 확인 순서

데스크톱 앱 안에서도 이 오류가 난 사례가 있습니다. macOS 26.1013.40934에서 내장 브라우저 탭이 화면에 열려 있는데도 에이전트가 빈 브라우저 목록과 이 오류를 받은 #55173, Windows 데스크톱에서 새 대화로도 해결되지 않았다는 #58856 등입니다.

OpenAI의 브라우저 확장 문서에 있는 "ChatGPT가 브라우저에 연결하지 못할 때" 점검 목록 가운데 내장 브라우저에도 해당하는 항목은 다음과 같습니다. 이 목록은 이 오류 문구를 직접 언급하지 않으므로, 일반 연결 점검으로 보면 됩니다.

1. 데스크톱 앱을 업데이트합니다. ChatGPT나 Codex 데스크톱 앱이 둘 이상 설치되어 있다면 모두 업데이트하거나 쓰지 않는 사본을 지웁니다.
2. 새 Codex 또는 Work 대화를 시작해 다시 시도합니다. 문서는 대화별 연결 상태가 이것으로 초기화될 수 있다고 설명합니다.
3. 데스크톱 앱을 완전히 종료한 뒤 다시 엽니다. 창만 닫지 말고 메뉴 막대나 시스템 트레이에서 앱을 끝냅니다.
4. 그래도 안 되면 앱에서 /feedback을 실행하고, 지원팀에 연락할 때 대화 ID를 함께 보냅니다.

#58856에서는 한 사용자가 2026년 11월 4일, Windows 데스크톱 패키지를 26.1029.7803.0으로 업데이트하고 VS Code를 닫은 뒤 데스크톱 앱을 완전히 종료했다가 다시 열자 Work와 Codex 대화 모두에서 브라우저 제어가 돌아왔다고 적었습니다. 같은 컴퓨터의 VS Code 확장은 여전히 실패했습니다. 한 사람의 결과일 뿐 확인된 수정은 아니지만, 위 순서(업데이트 → 새 대화 → 완전 재시작)와 같은 방향입니다.

@Chrome 등 브라우저 확장 경로의 확인 순서

데스크톱 앱에서 @Chrome, @Edge, @Brave처럼 평소 브라우저를 부를 때 이 오류가 났다면(#59756은 macOS의 Codex 대화에서 @Chrome으로 겪은 사례), 브라우저 확장 문서의 점검 순서를 처음부터 따라갑니다.

1. 차단 목록을 확인합니다. Settings > Computer Use에서 브라우저 옆 Manage를 눌러, 접속하려는 사이트가 blocklist(차단 목록)에 있지 않은지 봅니다.
2. 데스크톱 앱을 업데이트합니다. 여러 개 설치되어 있으면 모두 업데이트하거나 안 쓰는 사본을 지웁니다.
3. 브라우저를 다시 시작합니다. Chrome·Edge·Brave·Vivaldi에서는 툴바나 확장 메뉴로 ChatGPT를 다시 열어 사이드 채팅이 뜨는지 확인합니다. Opera는 사이드 채팅이 없으니 데스크톱 앱에서 연결을 확인합니다.
4. Settings > Computer Use에서 브라우저가 Manage로 보이는지 확인합니다. 아직 Install로 보이면 설치가 끝나지 않은 것이니 설정 과정을 다시 진행합니다.
5. @ 메뉴에 브라우저가 없으면 Computer Use에서 그 브라우저의 토글을 켭니다. 토글이 @ 메뉴 노출 여부를 정합니다.
6. 확장을 설치한 브라우저 프로필을 쓰고 있는지 확인합니다. 프로필이 여러 개라면 지금 쓰는 프로필에도 확장을 설치하고 켭니다.
7. 새 ChatGPT Work 또는 Codex 대화를 시작해 다시 시도합니다.
8. 데스크톱 앱을 다시 시작합니다. 그래도 연결되지 않으면 Settings > Computer Use에서 확장을 다시 설치합니다.
9. 마지막으로 앱에서 /feedback을 실행하고, 지원팀에 대화 ID를 함께 보냅니다.

화면 이름(Settings > Computer Use, Manage, Install, Work)은 영문 문서 기준 표기입니다. #58856처럼 확장 사이드 패널은 정상인데 에이전트 쪽에서만 실패하는 경우도 있으니, 3번에서 사이드 채팅이 뜬다고 확장 문제가 없다고 단정하지 말고 끝까지 진행하세요.

비슷하지만 다른 메시지

다음 메시지는 이 오류와 다른 검사에서 나오므로 위 순서로는 풀리지 않습니다.

• Local browser use is disabled in Work settings: 설정은 켜져 있는데 간헐적으로 막히는 증상으로, Windows에서 작업 관리자로 앱을 끝내고 다시 열었더니 풀렸다는 OpenAI 커뮤니티 보고가 있습니다.
• Disabled by your organization or unavailable in your region: Settings > Browser에 표시되는 조직 정책·지역 제한 메시지입니다.
• Windows에서 Browser Use가 failed to start codex app-server ... (os error 3)로 실패하거나, 확장 사이드 패널에 manifest entry is missing required path nodePath가 뜬다면 업데이트 뒤 남은 낡은 경로 문제입니다. failed to start codex app-server 해결: Windows 앱·CLI 오류 문구별 조치를 보세요.

수정 버전은 있나: 2026년 11월 11일 기준 OpenAI 답변 없음

2026년 11월 11일 기준으로 이 오류를 다룬 openai/codex 이슈는 20건이 넘고, 거의 모두 열려 있습니다. 이 이슈들에 OpenAI 메인테이너의 답변은 없고, 중복 이슈를 표시하는 봇 댓글만 달려 있습니다. 해결됨으로 표시된 이슈도 없습니다. #56928에는 OpenAI의 AI 지원 창구가 로그를 받은 뒤 GitHub 이슈로 안내했다는 사용자 글이 있습니다.

릴리스 노트에도 관련 수정이 없습니다. 변경 기록의 최신 항목은 Codex CLI 0.167.0(11월 6일)과 0.167.1(11월 10일)인데, 어느 쪽도 브라우저 접근 수정을 언급하지 않습니다. 데스크톱 앱 릴리스 노트는 26.1007 이후 올라오지 않았습니다. 따라서 어떤 버전에서 고쳐졌다고 말할 근거는 없고, OpenAI가 CLI·IDE의 브라우저 접근을 다시 열 계획인지도 공개되지 않았습니다.

수정을 확인하는 방법은 단순합니다. CLI나 데스크톱 앱이 업데이트되면 변경 기록에서 browser 관련 항목을 찾아보고, 터미널에서 @Browser로 열린 탭 목록을 요청해 이 오류가 사라졌는지 보면 됩니다.

신고할 때 함께 적을 버전 정보

새 이슈를 열면 봇이 중복으로 처리하는 경우가 많으므로, 사용자들은 #57641에 댓글로 환경을 덧붙이고 있습니다. 데스크톱 앱 안에서 난 문제라면 OpenAI 문서대로 앱에서 /feedback을 실행하고 대화 ID를 지원팀에 보냅니다.

자주 묻는 질문

Codex CLI를 예전 버전으로 되돌리면 @Browser가 다시 되나요?

CLI를 0.164.0으로 되돌려도 해결되지 않았다는 보고가 #57641에 있습니다. 막히는 지점이 CLI가 아니라 데스크톱 앱이 띄우지 않은 세션의 접근 확인이라는 사용자 분석과도 맞는 결과입니다. 반대로 데스크톱 앱을 최신 26.1103.60933으로 올려도 CLI 0.166.0에서는 같은 오류가 재현됐습니다.

Chrome 확장을 다시 설치하면 CLI의 @Browser가 돌아오나요?

CLI·IDE에서만 실패하고 같은 컴퓨터의 데스크톱 대화에서는 브라우저가 동작한다면, 확장은 정상이고 막힌 곳은 CLI 세션의 접근 확인입니다. 이 경우 확장 재설치로 해결됐다는 보고는 없습니다.

Codex 앱과 ChatGPT 데스크톱 앱 중 어디서 브라우저 작업을 해야 하나요?

둘은 같은 앱입니다. 그 앱에서 새 Codex 또는 Work 대화를 열고 @Browser나 @Chrome을 부르면 됩니다. OpenAI 문서가 Browser를 쓸 수 있는 위치로 안내하는 곳이 바로 이 대화입니다.