Codex /status 사용법: 모델·권한 확인 후 작업 시작하기 | DAKER 커뮤니티
큰 수정을 맡기기 전, 화면에는 이미 답이 하나 떠 있습니다. Codex /status 명령은 현재 작업 세션의 모델, reasoning, 권한, sandbox, 승인 상태를 확인해 작업 전 위험도를 맞추는 체크포인트입니다. Codex /status 사용법이란 긴 수정이나 외부 명령 실행 전에 현재 세션 설정을 확인하고, 필요하면 권한과 모델 선택을 조정하는 루틴입니다.
문제 상황: 왜 작업 시작 전에 /status를 봐야 할까요?
테스트만 돌릴 생각이었는데 패키지 설치가 필요해지고, 읽기만 하려던 작업이 파일 수정으로 바뀌는 순간이 있습니다. 이때 현재 세션이 read-only인지, workspace-write인지, 네트워크나 승인 흐름이 어떻게 잡혀 있는지 모르면 작은 요청도 멈추거나 과하게 열릴 수 있습니다. 2026년 8월 8일 KST 기준 OpenAI Codex 공식 문서는 작업에 맞는 model, reasoning effort, permissions, commands를 선택할 수 있다고 설명합니다.
한 줄 요약: /status는 “지금 Codex가 어떤 힘으로 움직이는지”를 확인하는 출발선입니다.
권한 흐름을 더 넓게 보려면 Codex auto-review 설정법을 같이 보고, 기본 작업 루프는 Codex 도구 사용법으로 잡아 두면 좋습니다.
핵심 개념: /status 화면에서 무엇을 먼저 봐야 하나요?
/status는 단순한 상태 표시가 아니라 작업 전 의사결정 표입니다. 모델과 reasoning은 답변 품질과 속도에 영향을 주고, sandbox와 approvals는 파일 수정과 명령 실행의 경계를 정합니다. 오늘 할 일이 읽기인지, 수정인지, 외부 시스템 변경인지에 맞춰 네 항목을 먼저 맞추면 중간에 멈추는 시간이 줄어듭니다.
| 확인 항목 | 왜 중요한가 | 바로 할 판단 |
|---|---|---|
| 모델 | 작업 난도와 비용에 영향을 줍니다. | 간단한 조회인지 복잡한 설계인지 나눕니다. |
| reasoning | 깊게 생각해야 하는 정도를 정합니다. | 리뷰·설계는 높게, 단순 조회는 낮게 둡니다. |
| sandbox | 파일과 명령 실행 경계를 정합니다. | 읽기 전용인지 수정 가능한지 확인합니다. |
| approvals | 위험 명령이 멈추는 방식을 정합니다. | 네트워크·외부 변경이 있으면 승인 기준을 봅니다. |
단계별 사용법: /status 확인은 어떤 순서로 루틴화하나요?
처음에는 매 작업마다 20초만 투자하면 충분합니다. 중요한 건 상태를 보는 데서 끝내지 않고, 오늘 작업의 위험도와 맞지 않는 부분을 바로 조정하는 것입니다.
- 작업을 시작하기 전에 /status로 현재 모델, reasoning, sandbox, approval 상태를 확인합니다.
- 오늘 요청이 읽기, 수정, 네트워크, 배포 중 어디에 가까운지 한 문장으로 정합니다.
- 읽기와 분석만 필요하면 read-only 성격의 흐름으로 유지하고, 수정이 필요하면 변경 범위를 작게 둡니다.
- 패키지 설치, 외부 API 호출, 운영 상태 변경이 있으면 approval이 어떻게 걸리는지 먼저 확인합니다.
- 상태가 작업 위험도와 맞지 않으면 /permissions나 설정 변경을 먼저 검토합니다.
- 작업이 끝나면 실행한 명령과 검증 결과를 남겨 다음 사람이 같은 상태를 재현할 수 있게 합니다.
짧은 예시: 작업을 맡기기 전 어떻게 말하면 좋을까요?
이렇게 시작하면 됩니다. “먼저 /status 기준으로 현재 모델, reasoning, sandbox, approval 상태를 확인하고, 이 작업이 읽기 전용으로 가능한지 판단해 주세요. 수정이 필요하면 어떤 권한이 필요한지 먼저 보고한 뒤 진행하고, 외부 네트워크나 패키지 설치가 필요하면 승인 요청 전 이유를 설명해 주세요.”
이 문장은 Codex에게 바로 고치라고 재촉하지 않습니다. 대신 현재 설정과 작업 위험도를 맞추는 장면을 먼저 만듭니다.
실수 방지 체크리스트: /status를 보고도 놓치기 쉬운 점은 무엇인가요?
- 모델 이름만 보고 끝내지 말고 sandbox와 approval 상태를 함께 확인합니다.
- 읽기 전용 작업을 수정 가능한 권한으로 오래 끌고 가지 않습니다.
- 패키지 설치와 네트워크 호출은 테스트 명령보다 위험도가 높다고 봅니다.
- 승인 요청이 뜨면 “왜 필요한지, 대안은 없는지”를 먼저 읽습니다.
- 팀 반복 작업은 Codex AGENTS 파일 사용법처럼 저장소 지침으로 옮겨 둡니다.
공식 출처는 어디를 확인했나요?
작성 기준일에는 OpenAI Codex 공식 문서의 CLI, developer commands, agent approvals and security 항목을 비공개로 확인했습니다. 공개 본문 정책상 외부 공식 문서 주소는 본문 링크로 넣지 않았습니다. 이어서 볼 내부 링크는 DAKER 코덱스 디렉터리입니다.
자주 묻는 질문
/status는 매번 실행해야 하나요?
큰 수정, 외부 명령, 새 저장소 작업 전에는 실행하는 편이 좋습니다. 단순 질문만 할 때는 필요성이 낮습니다.
/status가 권한을 바꿔 주나요?
아닙니다. /status는 현재 상태를 보여 주는 체크포인트입니다. 바꾸려면 권한 관련 명령이나 설정 변경을 별도로 검토해야 합니다.
read-only면 아무 작업도 못 하나요?
파일 수정은 제한되지만 코드 읽기, 계획 세우기, 리뷰, 원인 분석에는 충분한 경우가 많습니다. 수정 전 검토 단계에 특히 유용합니다.
approval이 많으면 나쁜 설정인가요?
항상 그렇지는 않습니다. 외부 상태 변경이나 위험 명령이 있는 작업에서는 승인 대기가 사고를 막는 장치가 됩니다.
다음 Codex 작업을 시작할 때는 첫 문장에 “/status부터 확인해 주세요”를 넣어 보세요. 설정을 먼저 본 뒤 맡기는 습관이 작업 속도보다 먼저 안전선을 잡아 줍니다.