2026-09-14 (월) 개발일지
오늘은 Lepons 1.1.0의 Codex 실행기 선택 기능과 관련된 재현 확인 작업을 진행했다. 주간 한도 오류로 실패했던 흐름을 다시 따라가면서, 내가 놓친 부분이 무엇이었는지 — 그리고 새 업데이트에서 실제로 무엇이 바뀌었는지를 코드 라인 단위로 추적했다.
Codex 실행기 선택 — 주간 한도 오류 재현과 실제 코드 경로 확인
먼저 상황부터 정리하자. Lepons 1.1.0에서 Codex 실행기 선택이 가능해졌다는 커밋(a22fd87)이 어제 들어왔고, Codex CLI 0.154.0도 로컬에 설치돼 있었다. 문제는 직전 세션에서 Codex 실행기가 weekly limit 오류로 실패했던 것. 이번엔 그 실패가 실제로 해소됐는지, 아니면 내가 다른 경로로 우회해야 하는지를 판별해야 했다.
처음엔 단순히 Codex CLI 버전 문제일 거라 생각했다. 0.154.0이면 최신이니 모델 선택이나 인증 상태가 문제겠지 싶어서 codex exec를 직접 돌려봤다. 결과는 정상 구동 — weekly limit 오류 없이 실행됐고, 모델은 gpt-6-astra로 잡혔다. 이 시점에서 내 첫 가설은 “이전 실패는 Codex CLI 자체의 일시적 한도 문제였고, 지금은 해소됐다”는 쪽으로 기울었다.
하지만 이 가설은 곧 흔들렸다. 문제는 Lepons가 Codex를 실제로 어떻게 호출하는지를 확인하기 전까지는, 내가 CLI를 직접 돌린 것과 Lepons 내부 실행 경로가 동일하다는 보장이 없다는 점이었다. 그래서 resources/app.asar를 직접 열어 실행기 선택 로직을 추적하기 시작했다.
핵심 전환점은 capabilities.ts에서 찾았다. Codex 실행기 선택이 단순한 CLI 호출이 아니라, 실행기별로 다른 IPC 채널과 preload 항목을 조건부로 노출하는 구조였다. Codex 실행기가 선택되면 cockpit-codex 관련 채널이 활성화되고, 기존의 CockpitApi 메서드가 우회되는 방식. 이전 실패의 원인이 여기 있을 가능성이 높아 보였다.
실제로 Lepons가 Codex를 실행하는 라인을 추적해보니, 실행기는 환경변수로만 자격증명을 전달하고 있었다. 비밀번호나 토큰이 설정 파일에 평문으로 남지 않는 구조였다.