Codex worktree index.lock 오류, 삭제 전 3가지 확인

index.lock 오류가 나오면 잠금 파일부터 지우지 마세요. 먼저 오류의 마지막 문구가 File exists, Permission denied, Read-only file system 중 무엇인지 보고, Git이 이 worktree에서 실제로 쓰는 잠금 경로와 그 파일을 사용 중인 프로세스가 있는지 확인해야 합니다.

먼저 오류 문구로 갈라보기

오류 끝 문구	먼저 의심할 것	첫 행동
File exists	다른 Git 작업이 진행 중이거나, 중단된 작업이 잠금 파일을 남김	실제 lock 경로와 보유 프로세스 확인
Permission denied / Operation not permitted	폴더 권한, ACL, 보안 정책	삭제보다 경로의 쓰기 권한과 실행 환경 확인
Read-only file system	Codex sandbox가 실제 Git 메타데이터 경로를 쓰지 못함	linked worktree의 공용 저장소 경로와 sandbox 범위 확인

문구가 다르면 해결법도 다릅니다. Permission denied인데 빈 lock 파일을 찾는 데 시간을 쓰거나, 실제 Git 작업이 진행 중인데 lock을 지우면 원인을 더 키울 수 있습니다.

1. 실제 잠금 경로부터 확인하기

macOS에서는 Command + Space → 터미널 → Enter로 터미널을 열고, Codex에서 작업 중인 폴더로 이동합니다. 그다음 아래 명령을 실행합니다.

git rev-parse --show-toplevel
git rev-parse --git-path index.lock

첫 줄은 Git이 보는 프로젝트 루트, 둘째 줄은 현재 worktree가 사용하는 index.lock 경로를 보여줍니다. linked worktree에서는 작업 폴더의 .git이 디렉터리가 아니라 공용 저장소의 메타데이터를 가리킬 수 있습니다. 그래서 .git/index.lock을 추측해서 찾지 말고 --git-path의 출력을 기준으로 삼아야 합니다.

Git 공식 rev-parse 문서는 --git-path <path>가 $GIT_DIR 아래의 저장소 경로를 해석하고, worktree 관련 경로 재배치 설정도 반영한다고 설명합니다.

2. File exists면 사용 중인지 먼저 확인하기

macOS와 Linux에서는 방금 나온 경로를 다음처럼 확인합니다.

LOCK_PATH="$(git rev-parse --git-path index.lock)"
ls -l "$LOCK_PATH"
lsof "$LOCK_PATH"

• lsof에 Git·Codex 관련 프로세스가 나오면 그 작업이 끝나는지 먼저 확인합니다. 실행 중인 commit, add, rebase, IDE 작업을 강제 종료하거나 lock을 지우지 않습니다.
• 파일은 있는데 lsof가 아무것도 출력하지 않는다면 남은 잠금 파일일 가능성이 있습니다. 열려 있는 터미널·Codex 작업에서 Git 명령이 정말 끝났는지 확인한 뒤, 삭제 대신 다른 이름으로 옮겨 보존하는 편이 원상복구하기 쉽습니다.
• 파일이 없다면 동일 오류를 다시 만들지 말고, 오류 전문과 발생 시각을 보존해 어떤 프로세스가 생성했는지 좁힙니다.

mv "$LOCK_PATH" "${LOCK_PATH}.stale-$(date +%Y%m%d-%H%M%S)"
git status

이 이동은 보유 프로세스가 없고 Git 작업도 끝난 것을 확인한 경우에만 합니다. 공개 Codex 이슈 #41305는 취소된 백그라운드 Git 작업 뒤 0바이트 lock이 남고, 당시 Git 프로세스가 없었던 사례를 기록합니다. 이 단일 Windows 사례를 모든 File exists 오류의 원인으로 일반화할 수는 없습니다.

3. 권한·읽기 전용 오류면 lock을 지우지 않기

Permission denied, Operation not permitted, Read-only file system은 기존 lock의 존재보다 새 lock 파일을 만들 권한이 없는 문제일 수 있습니다. 아래 값부터 기록합니다.

git rev-parse --git-dir
git rev-parse --git-path index.lock
ls -ld "$(git rev-parse --git-dir)"

linked worktree에서는 실제 경로가 메인 저장소의 .git/worktrees/<이름>/index.lock일 수 있습니다. OpenAI Codex 이슈 #23661은 작업 폴더에는 쓸 수 있어도 이 공용 메타데이터 경로가 sandbox에서 읽기 전용이면 git add가 실패하는 재현을 제시합니다. 이때 작업 폴더 안의 파일을 지우거나 chmod -R로 전체 저장소 권한을 넓히는 것은 문제의 경로를 맞히지 못하고 보안 범위만 넓힐 수 있습니다.

다음 정보를 함께 남기면 앱 문제와 저장소 문제를 구분하기 쉽습니다.

Codex App 또는 CLI 버전:
운영체제:
오류 전문:
git rev-parse --show-toplevel 결과:
git rev-parse --git-dir 결과:
git rev-parse --git-path index.lock 결과:
같은 폴더의 일반 터미널에서 git status 성공 여부:

경로에 사용자 이름·회사명·저장소명이 들어가면 공개 이슈에 올리기 전에 가립니다.

직접 재현한 결과

2026년 9월 19일 macOS, Git 2.38.1의 비민감 임시 저장소와 linked worktree에서 확인했습니다.

조건	실제 lock 경로	git add 결과
일반 저장소에 빈 index.lock 생성	메인 저장소 .git/index.lock	File exists, 종료 128
linked worktree에 빈 lock 생성	메인 저장소 .git/worktrees/<이름>/index.lock	File exists, 종료 128
linked worktree의 Git 메타데이터 디렉터리를 쓰기 불가로 변경	같은 공용 경로	Permission denied, 종료 128
lock 제거·권한 복원	같은 공용 경로	git add 성공, 종료 0

이 재현은 오류 문구와 실제 경로를 구분할 수 있음을 보여줍니다. Codex App 자체가 lock을 남겼다는 재현은 아니며, Windows ACL과 Linux sandbox 동작도 이번 로컬 재현 범위에 포함하지 않았습니다.

빠른 판단 순서

1. 오류 전문의 마지막 문구를 복사합니다.
2. git rev-parse --git-path index.lock으로 실제 경로를 확인합니다.
3. File exists면 lsof로 보유 프로세스를 확인합니다.
4. 보유 프로세스가 있으면 기다리거나 해당 작업을 정상 종료합니다.
5. 보유 프로세스가 없고 모든 Git 작업이 끝났을 때만 lock을 다른 이름으로 옮긴 뒤 git status를 확인합니다.
6. 권한·읽기 전용 오류면 삭제를 반복하지 말고 Git 메타데이터 경로와 Codex sandbox 범위를 조사합니다.

상위 검색 답과 다른 점

2026년 9월 19일 Google과 Naver에서 Codex worktree index.lock을 검색해 상위 일반 결과를 대조했습니다. Google 상위 결과는 동시 Git 쓰기를 직렬화하라는 글, linked worktree 메타데이터가 읽기 전용이라는 OpenAI 공개 이슈, Operation not permitted 공개 질문이었습니다. Naver에서는 같은 OpenAI 이슈가 정확 질문을 답했고 나머지 상위 결과는 worktree 일반 설명이 많았습니다. 정확 순위와 월간 검색량은 이 관찰로 단정하지 않습니다.

경쟁 글 하나는 worktree들이 하나의 index를 공유한다고 설명하지만, Git이 계산한 실제 경로와 이번 재현에서는 linked worktree마다 .git/worktrees/<이름>/index가 따로 있었습니다. 공용 저장소 경로를 함께 쓰는 것은 맞아도 모든 오류를 동시 쓰기 충돌로 볼 수는 없습니다. 이 글은 오류 끝 문구와 실제 경로를 먼저 확인해 stale lock과 권한 문제를 갈라냅니다.

자주 묻는 질문

index.lock 파일이 보이면 바로 지워도 되나요?

아닙니다. lsof "$LOCK_PATH"에 보유 프로세스가 없고 열려 있던 Git 작업이 모두 끝난 것을 확인한 뒤에만 stale lock 후보로 판단합니다. 바로 삭제하기보다 다른 이름으로 옮기면 git status가 실패할 때 되돌릴 수 있습니다.

linked worktree인데 .git/index.lock만 찾으면 되나요?

아닙니다. git rev-parse --git-path index.lock의 출력을 사용합니다. linked worktree에서는 공용 저장소의 .git/worktrees/<이름>/index.lock이 나올 수 있습니다.

Permission denied도 파일 이동으로 해결되나요?

그렇게 단정할 수 없습니다. 기존 lock이 아니라 새 lock을 만들 권한이 없는 상태일 수 있습니다. git rev-parse --git-dir과 실제 lock 경로, 같은 폴더의 일반 터미널 결과를 함께 기록한 뒤 폴더 권한과 Codex sandbox 범위를 확인합니다.

저장소에 첫 커밋이 없다는 invalid reference: HEAD가 함께 보인다면 Codex Desktop worktree의 HEAD 확인 순서를 먼저 확인하세요. .gitignore에 넣은 파일이 이미 추적 중인 문제는 추적에서 안전하게 빼는 순서가 별도 질문을 답합니다.

검증 기준

• 마지막 업데이트일: 2026-09-19
• 확인 환경: macOS, Git 2.38.1, 비민감 임시 일반 저장소와 linked worktree
• 직접 확인: 실제 lock 경로, File exists, Permission denied, 권한 복원 뒤 git add 성공
• 직접 확인하지 않음: Codex App가 lock을 남기는 장면, Windows ACL, Linux sandbox의 실제 실패 화면
• 공개 질문 근거: OpenAI Codex 이슈 #41305, #23661, #19190. 모두 공개 신고이며 모든 계정·버전의 동작을 확정하는 공식 해결 공지는 아닙니다.
• 주요 근거: Git rev-parse 공식 문서, OpenAI Codex linked worktree 공개 이슈