Codex /status로 모델·권한 확인하는 법: 작업 전 위험도부터 맞추기 | DAKER 커뮤니티
큰 수정을 맡기기 전에는 이미 화면에 중요한 단서가 떠 있는 경우가 많습니다. Codex의 /status는 현재 작업 세션의 모델, reasoning, 권한, sandbox, 승인 상태를 보여 주는 체크포인트입니다. 긴 수정이나 외부 명령 실행 전에 이 화면을 먼저 보면, 지금 세션이 작업에 맞는지 빠르게 판단할 수 있습니다.
테스트만 돌릴 줄 알았는데 패키지 설치가 필요해지거나, 읽기만 하려던 작업이 파일 수정으로 바뀌는 순간이 있습니다. 이럴 때 현재 세션이 read-only인지, workspace-write인지, 네트워크나 승인 흐름이 어떻게 잡혀 있는지 모르면 작은 요청도 멈추거나 반대로 과하게 열릴 수 있습니다.
왜 작업 시작 전에 /status를 봐야 할까요?
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를 보고도 놓치기 쉬운 점
/status를 확인했더라도 몇 가지는 따로 의식해 두는 것이 좋습니다. 모델 이름만 보고 끝내지 말고 sandbox와 approval 상태를 함께 봐야 합니다. 읽기 전용 작업을 수정 가능한 권한으로 오래 끌고 가지 않는 편이 좋고, 패키지 설치와 네트워크 호출은 테스트 명령보다 위험도가 높다고 보는 편이 안전합니다. 승인 요청이 뜨면 왜 필요한지, 대안은 없는지를 먼저 읽어 보는 것이 좋습니다.
팀에서 반복되는 작업이라면 Codex AGENTS 파일 사용법처럼 저장소 지침으로 옮겨 두면 같은 확인을 덜 반복하게 됩니다.
자주 묻는 질문
/status는 매번 실행해야 하나요?
큰 수정, 외부 명령, 새 저장소 작업 전에는 실행하는 편이 좋습니다. 단순 질문만 할 때는 필요성이 낮습니다.
/status가 권한을 바꿔 주나요?
아닙니다. /status는 현재 상태를 보여 주는 체크포인트입니다. 바꾸려면 권한 관련 명령이나 설정 변경을 별도로 검토해야 합니다.
read-only면 아무 작업도 못 하나요?
파일 수정은 제한되지만 코드 읽기, 계획 세우기, 리뷰, 원인 분석에는 충분한 경우가 많습니다. 수정 전 검토 단계에 특히 유용합니다.
approval이 많으면 나쁜 설정인가요?
항상 그렇지는 않습니다. 외부 상태 변경이나 위험 명령이 있는 작업에서는 승인 대기가 사고를 막는 장치가 됩니다.
참고 자료
작성 기준일에는 OpenAI Codex 공식 문서의 CLI, developer commands, agent approvals and security 항목을 비공개로 확인했습니다. 함께 볼 수 있는 공개 링크로는 DAKER 코덱스 디렉터리, Codex auto-review 설정법, Codex 도구 사용법, Codex AGENTS 파일 사용법이 있습니다.
여러분은 Codex 작업을 시작할 때 어떤 상태 항목을 가장 먼저 확인하는 편인가요?