매일 기록한 AI 기록

남이 만든 저장소에서 코딩 에이전트를 켜면 내가 입력하지 않은 지침이 문맥에 먼저 들어간다. Codex와 Claude Code가 시작할 때 정해진 경로의 지침 파일을 찾는 조건에서 그렇다. 공식 문서와 실험은 모두 2026-11-09 KST에 확인했다. 실행 전에 소스 코드뿐 아니라 지침 파일과 훅, MCP 설정 목록을 먼저 뽑아 읽어야 한다. AGENTS.md 자동 로딩은 언제 일어나는가 왜 프롬프트에 없던 규칙이 응답에 따라붙을까. 에이전트는 세션을 시작할 때 정해진 경로의 파일을 찾아 문맥에 합치기 때문이다. OpenAI의 Custom instructions with AGENTS.md 문서를 보면 Codex는 ~/.codex 의 전역 지침에 이어 프로젝트 루트부터 현재 작업 디렉터리까지 내려간다. 디렉터리마다 AGENTS.override.md , AGENTS.md , project_doc_fallback_filenames 에 지정한 이름 순으로 찾아 한 파일만 포함한다. 합친 크기가 project_doc_max_bytes 기본값 32 KiB에 도달하면 추가를 멈춘다. 현재 디렉터리까지의 경로만 보므로 하위 폴더 전체를 처음부터 읽지는 않는다. 실제로 반영되는지 macOS arm64의 codex-cli 0.166.0 으로 시험했다. 프로젝트 AGENTS.md 가 없는 새 Git 저장소에서 도구를 쓰지 말라는 프롬프트로 아래 명령을 실행했다. codex --no-daemon --ask-for-approval never \ -c 'log_dir="<폴더>/logs"' \ -c 'sqlite_home="<폴더>/state"' \ -c 'history.persistence="none"' \ -c 'web_search="disabled"' \ exec --ignore-user-confi...

Worktrunk는 git worktree 를 대체하는 격리 기술이 아니고, 브랜치 이름으로 작업 폴더의 생성·이동·상태 확인·병합·정리를 묶는 CLI다. 기존 커밋 하나를 main 에 fast-forward하고 정리하는 절차에서 셸 래퍼를 켠 Worktrunk는 6명령, 기본 Git은 9명령이었다. 2026-11-09 macOS arm64에서 Worktrunk v0.81.0 , Git 2.50.1 을 격리 실행한 결과다. Worktrunk가 덜어 주는 것은 브랜치 이름과 경로를 오가는 이동과 정리 절차다. git worktree와 Worktrunk는 무엇이 다른가 작업 폴더 분리는 기본 Git이 이미 한다. Git 공식 git-worktree 매뉴얼(2026-11-09 확인)은 git worktree add 로 연결된 작업 디렉터리를 만들고 list , remove , prune 으로 관리한다고 설명한다. 두 도구 모두 모델의 파일 접근이나 네트워크를 막는 보안 샌드박스는 아니다. 차이는 이동 단위다. Worktrunk v0.81.0 릴리스 참조 문서(2026-11-09 확인)에 따르면 wt switch 는 브랜치에 대응하는 작업 폴더를 찾거나 만든다. 같은 폴더에서 브랜치만 바꾸는 git switch 와 다르다. 에이전트마다 브랜치별 폴더를 나눠 주며 경로를 직접 따라가는 일이 번거롭다면 검토할 만하다. 같은 작업에서 명령 수는 얼마나 달랐나 부모 커밋을 main , 릴리스 태그 v0.81.0 을 feature 로 두고 양쪽에서 생성, 목록, 이동, 병합, 정리를 직접 실행해 봤다. Worktrunk는 일회성 자식 Bash에서 셸 래퍼를 켠 뒤 아래 6명령을 썼다. wt switch --create feature --base v0.81.0 --no-hooks wt list wt switch main --no-hooks wt switch feature --no-hooks wt merge main --no-commit --no-rebase -...

agent-browser 는 접근성 트리 snapshot과 @e 참조로 브라우저를 조작하는 CLI다. macOS arm64와 Node v26.10.0 에서 agent-browser@0.41.2 를 격리 폴더에 설치하고, 외부 자원이 없는 로컬 HTML 한 페이지에서 클릭 뒤 snapshot 재확인까지 검증했다. 문서 확인과 실험은 2026-11-09 KST에 했다. 이 테스트 페이지에서 전체 snapshot은 원시 HTML보다 74.19% 작으면서 -i 에 빠진 상태 문구를 담아 행동 뒤 검증에 썼다. agent-browser 설치와 snapshot으로 확인할 것 원시 HTML을 통째로 넘기면 조작과 무관한 마크업까지 함께 읽힌다. 반대로 조작 대상만 추리면 클릭 뒤 상태가 바뀌었는지 놓칠 수 있다. 그렇다면 시스템 설정을 건드리지 않고 설치해 열기부터 종료까지 돌릴 수 있을까. 출력 바이트는 원시 HTML과 얼마나 다를까. 공식 문서가 설명하는 작동 방식 vercel-labs agent-browser 저장소의 README와 문서(릴리스 태그 v0.41.2 , 2026-11-09 KST 확인)를 기준으로 했다. 문서에 따르면 Rust CLI는 첫 명령에서 백그라운드 데몬을 띄운다. 데몬은 Chrome DevTools Protocol로 브라우저를 제어하고, 명령 사이에도 브라우저를 열어 둔다. Snapshots 문서는 snapshot 이 접근성 트리를 짧은 텍스트와 참조로 돌려주고, 이후 click @e2 처럼 조작한다고 설명한다. 요소가 교체되거나 페이지를 이동하면 ref가 무효화될 수 있다고도 적었다. 이번 실험 출력에서 참조는 [ref=e2] 형태로 나왔다. 브라우저 설치 위치는 cli/src/install.rs 의 get_browsers_dir() 가 정한다. 이 함수는 std::env::home_dir() 아래 .agent-browser/browsers 를 쓴다. Rust 공식 문서에 따르면 home_dir() 는 Unix에서 H...

Claude Code CLI에서 Bash 명령을 다시 묻지 않기로 승인하면 허용 규칙이 프로젝트의 .claude/settings.local.json 에 문자열로 저장된다. 규칙에 토큰이나 비밀번호가 평문으로 들어 있으면 값도 함께 남고, 이 파일을 공개 저장소에 커밋해 푸시하면 값도 공개된다. 공식 문서와 Apiiro 보고서는 2026-11-09 KST에 확인했고, Git 동작은 더미 파일로 직접 실행해 봤다. 영구 승인이 모든 명령을 덤프하지는 않지만, 비밀값이 든 정확한 명령을 승인하고 이 파일이 Git에 커밋되면 평문이 저장소에 남는다. Claude Code 비밀값 노출은 승인 규칙에서 어떻게 시작될까 다시 묻지 않기를 고른 승인은 어디에 남을까. Anthropic의 Configure permissions 공식 문서는 Bash 영구 승인이 저장소와 명령별로 지속된다고 설명한다. CLI 기준 저장 위치는 .claude/settings.local.json 이고, 규칙 형식은 Tool 또는 Tool(specifier) 다. Bash 규칙에 * 가 없으면 정확한 명령 전체를 허용한다. * 가 있으면 그 자리에 어떤 텍스트가 와도 허용한다. 그래서 아무 명령이나 한 번 승인하면 비밀값이 저장된다는 말은 과장이다. 반대로 헤더나 환경변수 할당에 실제 토큰을 넣은 명령을 정확한 규칙으로 승인하면, 그 문자열이 permissions.allow 에 평문으로 들어간다고 본다. 비밀값이 든 명령은 지속 승인을 거쳐 로컬 설정의 허용 규칙이 된다. 공개 저장소까지 이어지는 것은 Git 커밋과 공개 저장소 푸시가 겹칠 때뿐이다. 공개 저장소에서는 얼마나 발견됐을까 Apiiro의 보고서 Coding Agents Are Leaking Your Secrets to GitHub는 2026-11-01부터 03일까지 공개 GitHub 기본 브랜치를 읽기 전용으로 검색한 결과다. 아래 수치는 모두 Apiiro의 분류 결과이며, 이번에 다시 조사하지 않았다. 공개 .cl...

제미나이 CLI에서 Antigravity CLI(agy)로 옮긴 뒤 스크립트로 원고를 반복 생성한다면, 본문 출력과 프로세스 종료를 따로 판정해야 한다. 한 번에 한 요청만 직렬로 돌리고 부모 프로세스에서 외부 시간 제한을 거는 조건에서 세운 기준이다. 근거는 2026-10-16 운영 기록과 2026-11-03 로컬 agy 1.4.12 실측이다. agy 1.3.6에서 겪은 출력 후 미종료는 이 환경의 과거 운영 기록이고 1.4.12 실측 3건은 스스로 종료했으므로, 버전을 가정하지 말고 외부 제한과 출력 검수를 함께 둔다. 제미나이 CLI 다음, agy 반복 실행이 막히는 지점 Gemini CLI와 agy는 다른 도구다. 명령어와 JSON 규격, 설정 경로를 섞으면 안 된다. Google 개발자 블로그 공지(2026-05-19 발표)는 2026년 6월 18일부터 Gemini CLI가 요청 처리를 멈춘다고 알렸다. 대상은 Google AI Pro·Ultra와 Gemini Code Assist for individuals 무료 이용자이며, 모든 이용자가 아니다. 터미널에서 한 번 응답을 받는 것과 스크립트가 요청을 차례로 처리하는 것은 조건이 다르다. 스크립트는 화면을 보는 사람 없이 종료 코드와 표준 출력만으로 다음 단계를 정한다. 2026-10-16 운영 메모에는 agy 1.3.6에서 본문이 다 나온 뒤에도 프로세스가 끝나지 않은 일이 적혀 있다. 여러 요청을 동시에 띄웠을 때 출력 없이 멈춘 일도 함께 기록돼 있다. 그래서 첫 호출에 성공했다면 다음에 세울 것은 호출 명령보다 실행 대기열과 종료 판정 규칙이다. 문서와 도움말, 그리고 1.4.12 실측 Antigravity CLI 공식 헤드리스 문서(2026-11-03 확인)에 따르면 -p 또는 --print 는 요청 하나를 실행하고 끝낸다. 응답은 stdout 으로, 오류·인증 안내·진행 상태는 stderr 로 나간다. 같은 문서는 --print-timeout 기본값을 5m 으로 적는다...

코딩 에이전트 CLI에서 MCP 서버가 목록에 보여도 그것만으로 도구가 작동한다고 판정할 수는 없다. macOS의 로컬 stdio 서버 하나를 기준으로 하면 설정 읽기, 서버 초기화, 실제 도구 호출은 서로 다른 출력으로 확인해야 한다. 실측과 공식 문서 확인은 모두 2026-11-03에 했다. Codex에서는 없는 경로를 준 고장 설정도 enabled 로 표시됐다. 성공 여부는 mcp_tool_call 이벤트의 도구 이름과 반환값으로 판정해야 했다. MCP 서버가 목록에 있는데 왜 도구는 작동하지 않을까 MCP 공식 아키텍처·전송 문서에 따르면 로컬 stdio 연결에서 클라이언트는 서버를 자식 프로세스로 실행한다. 설정에 명령이 적혀 있는 것과 그 프로세스가 살아서 응답하는 것은 별개다. 그래서 이 글은 확인 과정을 등록·읽기, 시작·초기화, 실제 호출 세 단계로 나눈다. MCP 공식 명칭은 아니다. 실패 지점을 좁히려고 이 글에서 정한 진단 분류다. 설정 읽기가 통과해도 초기화나 도구 호출에서 멈출 수 있으므로 단계마다 다른 증거를 봐야 한다. 다른 폴더에서 서버가 보이지 않는 이유 Claude Code 공식 문서는 등록 범위를 local , project , user 로 나눈다. 기본값 local 은 현재 프로젝트에만 적용되며 ~/.claude.json 의 프로젝트 경로별 항목에 저장된다. Claude Code 2.1.274 와 codex-cli 0.161.0 으로 ~/workspace 에서 직접 실행해 봤다. claude mcp list 와 codex mcp list 모두 서버가 없다고 나왔다. ~/.claude.json 에서 프로젝트 키와 서버 이름만 뽑아 보니 홈 폴더( ~ ) 항목에는 chrome-devtools 가 있었고 ~/workspace 항목에는 서버가 없었다. local 범위에 등록한 서버를 전역 설정으로 오해하면 다른 폴더에서 서버가 사라진 것처럼 보인다. 설정 등록과 실제 도구 호출은 어떤 출력으로 구별하는가 ...