10월 8일 새벽, Codex가 또 응답하지 않았다.
"원인파악해봐"라고 맡긴 세션이 찾아낸 것은 존재하지 않는 폴더 하나였다.
맥의 OpenCodex 프록시를 정본으로 세운 한 달 동안 연결은 네 번 끊겼다.
복구는 매번 명령 한 줄이었고 코드는 한 줄도 고치지 않았다.
끊은 것은 서비스 정의에 고정된 폴더 경로, 오래 떠 있던 앱 서버,
그리고 에이전트가 건 재시작 작업이었다.
OpenCodex는 Codex의 요청을 받아 여러 회사의 모델로 넘겨 주는 프록시다.
9월 8일 오후 맥에 설치했고, 다음 날 새벽에 정한 목표는 한 줄이었다.
"맥북에서도 윈도우에서도 들어갈수있게해야해 같은페이지."
그 컷오버와 두 기계의 계정이 어긋난 일은 앞선 글에 적었다.
9월 22일에는 맥을 허브로 바꿨다.
윈도우에서 맥의 관리 화면을 열 때마다 관리자 토큰 입력창이 떴기 때문이다.
설정의 역할을 hub로 바꾸고 관리 포트를 Tailscale HTTPS로 내보냈다.
윈도우 PC가 그 주소에서 받은 첫 응답은 200이었다.
다음 날 저녁, 휴대폰에서 일이 꼬였다.
ChatGPT 앱에서 SSH로 맥에 접속해 일하는데
모델 목록에 Opus 5.5가 없었다.
디스크의 모델 캐시에는 그 모델이 들어 있었다.
옛 목록을 계속 가지고 있던 쪽은 9월 9일 새벽부터
14일 14시간 41분째 떠 있던 Codex 앱 서버로 보였다.
에이전트는 앱 서버를 다시 띄우는 작업을 launchd에 걸었다.
그 작업은 저녁 7시 31분부터 50분까지 36~37초 간격으로 32번 예약됐고
나는 그 직후 "계속 연결이끊겨. 제대로처리해"라고 쳤다.
launchctl remove로 작업을 제거한 뒤 에이전트가 보고한 첫 문장은
"원인은 제가 건 재시작 스크립트였습니다."였다.
같은 보고는 그 32번을 여덟 번이라고 적었다.
10월 7일 새벽에는 오래된 도구를 한꺼번에 업데이트했다.
에이전트가 낸 표를 보고 내가 "omo 뺴고 전부진행"이라고 답했다.
OpenCodex는 pnpm 전역 설치를 거쳐 2.75.0에서 2.78.0이 됐고
pnpm 전역 폴더에는 해시 이름의 새 폴더들이 생겼다.
그 몇 분 동안 프록시 서비스의 상태를 확인한 호출은 없었다.
다음 날 새벽, launchd의 OpenCodex 서비스는 8445번 기동을 시도했고
마지막 종료 코드는 126이었다.
서비스 정의에 적힌 bun 실행 파일의 해시 경로 폴더가 존재하지 않았다.
ocx service repair를 한 번 실행하자 프록시가 다시 올라왔다.
새 폴더의 수정 시각부터 복구를 확인한 시각까지는 24시간 29분이다
(그동안 내내 꺼져 있었는지는 요청 기록만으로 판단할 수 없다).
복구 보고를 받자마자 나는 "다시해봐 업데이트했어"라고 했다.
2.80.0 업데이트는 실패했는데 pnpm 전역 폴더에는 새 폴더가 또 생겼다.
프록시는 다시 응답하지 않았고 repair를 한 번 더 실행하고 나서야 올라왔다.
고치자마자 다시 끊은 것은 나였다.
네 번째는 10월 19일 아침이다.
다른 일을 하던 에이전트가 실행한 ocx status가 프록시가 꺼져 있다고 보고했고
서비스 정의에 고정된 경로 두 곳이 없다는
"STALE baked paths" 줄도 함께 출력됐다.
지금 쓰는 pnpm 전역 폴더는 그날 6시 30분에 생긴 것이었다.
이번에는 내가 직접 repair를 실행했다.
지금 프록시는 그때 뜬 프로세스로 돌고 있다.
서비스 정의는 여전히 폴더 해시를 글자 그대로 담고 있다.
허브라고 불렀지만 맥의 요청 기록 3,459줄 가운데
3,450줄은 인증 없는 loopback 리스너로 들어온 요청이었다.
버전은 2.78.0에 머물러 있고
다음 업데이트 뒤에 실행할 명령도 이미 정해져 있다.