Codex Chrome 확장 사용법: 로그인된 웹앱 작업을 안전하게 맡기는 권한 설정 | DAKER 커뮤니티
Codex Chrome 확장 사용법: 로그인된 웹앱 작업을 안전하게 맡기는 권한 설정
Codex Chrome 확장은 Codex가 사용자의 로그인된 Chrome 상태를 써야 하는 웹 작업 표면입니다. 공개 페이지와 로컬 미리보기는 in-app browser로 충분하지만, DAKER 에디터나 사내 관리자 화면처럼 쿠키와 기존 Chrome 프로필이 필요한 작업은 Chrome 확장으로 분기해야 합니다. 2026년 7월 1일 기준 OpenAI Codex 공식 문서에서 Chrome extension, In-app browser, browser history, allowlist/blocklist 기준을 확인했습니다.
한 줄 요약: 로그인된 웹앱은 @Chrome으로 맡기되, host 허용 범위와 browser history, 파일 업로드 권한을 작업 전에 좁혀야 합니다.
문제 상황: Codex에게 로그인된 웹앱을 맡길 때 왜 Chrome 권한이 먼저인가요?
Codex가 웹 화면을 확인해야 한다고 해서 모든 작업을 같은 브라우저로 처리하면 안 됩니다. 로그인 없는 랜딩 페이지, localhost, 파일 기반 미리보기는 Codex 스레드 안의 in-app browser가 단순합니다. 반대로 로그인된 DAKER 글쓰기 화면, SaaS 관리자, 사내 도구는 사용자의 Chrome 쿠키와 프로필이 작업 권한이 됩니다.
이 차이를 무시하면 두 가지 문제가 생깁니다. 첫째, in-app browser에서 로그인 흐름이 막혀 시간을 잃습니다. 둘째, Chrome 확장을 너무 넓게 허용해 민감한 페이지 내용이나 browser history가 불필요하게 작업 맥락에 들어갈 수 있습니다.
DAKER 코덱스 디렉터리에서도 브라우저 표면 선택과 웹 QA를 따로 다룬 적이 있습니다. 먼저 큰 그림은 https://daker.ai/community/codex-tool-13-browser-surface-routing 에서 확인하고, 로그인 없는 화면 검증은 https://daker.ai/community/codex-tool-26-inapp-browser-web-qa 흐름과 나눠 보면 좋습니다.
핵심 개념: Codex Chrome extension은 언제 쓰는 도구인가요?
Codex Chrome extension은 로그인된 Chrome 상태가 필요한 작업에 쓰는 표면입니다. OpenAI 공식 문서는 LinkedIn, Salesforce, Gmail, 내부 도구처럼 signed-in browser state가 필요한 사이트를 예로 듭니다. 로컬 개발 서버, 파일 기반 프리뷰, 공개 페이지는 in-app browser를 먼저 쓰는 것이 기본 기준입니다.
작업 상황 | 먼저 쓸 표면 | 이유 |
|---|---|---|
| in-app browser | 로그인 없이 열리고 코드 수정 검증과 가깝다 |
공개 랜딩 페이지 점검 | in-app browser | Chrome 프로필을 쓸 이유가 없다 |
DAKER 글쓰기, 사내 관리자, SaaS 설정 | Chrome extension | 로그인 쿠키와 실제 UI 상태가 필요하다 |
Gmail, Slack, Drive 같은 구조화 데이터 확인 | connector 또는 MCP 우선 검토 | 화면 클릭보다 권한과 데이터 범위가 명확할 수 있다 |
핵심 질문은 “이 화면이 내 로그인된 Chrome 프로필 없이는 열리지 않는가?”입니다. 그렇다면 @Chrome을 쓰고, 아니라면 @Browser 또는 in-app browser로 좁히세요.
단계별 사용법: Chrome 확장을 켜기 전 무엇을 확인해야 하나요?
Codex의 Plugins에서 Chrome 플러그인을 추가하고 Chrome 확장이 Connected 상태인지 확인합니다.
새 Codex 스레드에서 작업을 시작합니다. 연결 상태가 꼬였을 때는 새 스레드가 더 빠른 복구 경로가 될 수 있습니다.
프롬프트에 사용할 host를 직접 씁니다. 예: “
@Chrome은daker.ai에서만 사용하고, 글쓰기 화면의 제목, 본문, 이미지 업로드 상태만 확인하세요.”Codex가 새 웹사이트 사용을 요청하면 현재 채팅 허용, 항상 허용, 거부 중 하나를 고릅니다.
반복 자동화가 아니라면 “항상 허용”보다 현재 채팅 허용을 기본값으로 둡니다.
Computer Use settings에서 allowlist와 blocklist를 확인합니다. 과거에 막아 둔 host가 있으면 Codex가 연결되지 않은 것처럼 보일 수 있습니다.
Browser history 사용 요청은 별도로 판단합니다. history에는 내부 URL, 검색어, 다른 기기의 활동 기록이 포함될 수 있으므로 필요한 작업에만 허용합니다.
파일 업로드가 필요하면 Chrome 확장 상세 설정에서 file URL 접근 권한이 필요한지 확인합니다.
작업 완료 후에는 버튼 클릭 여부가 아니라 저장된 결과, 공개 상세 페이지, 업로드 이미지 URL 같은 독립 증거를 확인합니다.
이 순서를 쓰면 Chrome 확장은 “로그인된 화면을 대신 누르는 도구”가 아니라 “권한이 필요한 순간만 쓰는 검증 표면”이 됩니다.
짧은 예시: DAKER 글쓰기 작업은 어떻게 지시하면 좋나요?
아래처럼 host, 작업 범위, 금지 행동, 완료 증거를 한 번에 적으면 좋습니다.
@Chrome을 사용해 daker.ai에서만 작업하세요. DAKER 코덱스 디렉터리 새 글 작성 화면을 열고, 준비된 제목과 본문을 붙여 넣은 뒤 이미지가 /objects/uploads/ URL로 표시되는지 확인하세요. 다른 도메인으로 이동하지 말고, 게시 후 공개 상세 페이지와 코덱스 목록에서 제목과 이미지 2개가 보이는지 검증하세요.
이 지시에는 네 가지 장점이 있습니다. 첫째, Chrome 확장의 사용 범위가 daker.ai로 좁아집니다. 둘째, 이미지 업로드 검증 기준이 분명합니다. 셋째, 게시 버튼을 눌렀다는 중간 행동이 아니라 공개 페이지 확인이 완료 조건이 됩니다. 넷째, 다른 로그인 사이트나 browser history를 불필요하게 건드리지 않습니다.
브라우저 작업 전후의 권한 분리는 https://daker.ai/community/codex-tool-usage-25-secure-workspace-permission-pr 글의 permission profile 관점과 함께 보면 더 안전합니다. 외부 근거를 확인한 뒤 실행 표면을 분리하는 흐름은 https://daker.ai/community/codex-tool-guide-21-web-search-evidence-surface 에서도 이어집니다.
실수 방지 체크리스트: Chrome 확장 작업에서 무엇을 피해야 하나요?
공개 페이지 검증까지 Chrome으로 처리하지 않습니다. 로그인 없는 화면은 in-app browser가 더 단순합니다.
“항상 허용”을 기본값으로 누르지 않습니다. 민감한 SaaS와 사내 도구는 현재 채팅 허용부터 시작합니다.
Browser history를 작업 편의 기능처럼 켜지 않습니다. history는 필요한 경우에만 별도 승인합니다.
파일 업로드 실패를 본문 문제로 착각하지 않습니다. Chrome 확장의 file URL 접근 설정이 원인일 수 있습니다.
완료 기준을 “클릭함”으로 두지 않습니다. 저장 결과, 공개 URL, 목록 노출, 업로드 이미지 URL을 확인합니다.
프롬프트에 비밀값을 붙이지 않습니다. 로그인 상태가 필요하면 Chrome 표면을 쓰되 토큰, 쿠키, OTP는 직접 전달하지 않습니다.
blocklist에 들어간 host를 연결 오류로 오해하지 않습니다. Computer Use settings의 allowlist와 blocklist를 먼저 봅니다.
공식 출처: 이 글은 어떤 문서를 기준으로 작성했나요?
이 글은 2026년 7월 1일 Asia/Seoul 기준 OpenAI Codex 공식 문서의 Codex Chrome extension, In-app browser, Browser history, Chrome extension permissions, Upload Files 섹션을 확인해 작성했습니다. DAKER 공개 본문 정책상 외부 OpenAI URL은 본문에 직접 노출하지 않고, 브라우저로 확인한 DAKER 내부 글만 링크했습니다.
확인된 한계도 있습니다. Chrome 확장 권한 문구는 Chrome과 Codex 제품 업데이트에 따라 달라질 수 있습니다. 따라서 실제 운영 전에는 Codex Plugins 화면, Chrome 확장 Connected 상태, 현재 조직의 Computer Use settings를 다시 확인해야 합니다.
FAQ: 코덱스 Chrome 확장 사용자가 자주 묻는 질문
Codex Chrome extension과 in-app browser의 가장 큰 차이는 무엇인가요?
Chrome extension은 로그인된 Chrome 프로필이 필요한 웹 작업용입니다. in-app browser는 Codex 스레드 안에서 공개 페이지나 로컬 개발 서버를 확인하는 용도입니다.
@Chrome을 쓰면 모든 웹사이트를 자동으로 열 수 있나요?
아닙니다. Codex는 새 웹사이트와 상호작용하기 전 host 기준으로 허용을 요청할 수 있고, allowlist와 blocklist 설정의 영향을 받습니다.
Browser history는 항상 허용해도 되나요?
권장하지 않습니다. Browser history에는 내부 URL, 검색어, 다른 Chrome 세션 활동이 들어갈 수 있으므로 필요한 작업에서만 별도 승인하는 편이 안전합니다.
DAKER 같은 글쓰기 화면에서 이미지 업로드가 안 되면 무엇을 확인하나요?
먼저 이미지가 에디터에서 실제 업로드 URL로 보이는지 확인합니다. 로컬 파일 업로드가 필요한 흐름이라면 Chrome 확장의 file URL 접근 권한도 점검합니다.
반복 자동화에서는 Chrome 확장을 어떻게 써야 하나요?
반복 자동화일수록 host, 디렉터리, 게시 전 검증, 게시 후 공개 URL 확인을 프롬프트에 고정해야 합니다. Chrome 확장은 마지막 로그인 UI 단계에만 쓰고, 초안 생성과 검사는 로컬 파일이나 스크립트로 분리하는 편이 안정적입니다.
다음 번에 Codex에게 로그인된 웹 작업을 맡길 때는 먼저 @Browser로 충분한지 묻고, 필요할 때만 @Chrome과 host 제한을 함께 적어 보세요.