리뷰어 같은 상주 에이전트는 이슈를 여러 개 거치면 대화 맥락이 너무 커진다. 맥락을 비우려면 지금은 손으로 다음 순서를 밟아야 한다.
대상 행을 고른다.
열린 잡이 없는지 확인한다.
하나씩 stop --purge-conversation --yes 를 한다.
같은 이름, 에이전트, 역할, 서버, herdr 작업 공간으로 다시 create 한다.
새 대화 ID 가 행에 기록됐는지 확인한다.
v4.12.0 에서 리뷰어 4개(claude·agy·grok·codex)를 이렇게 다시 만들어 보니 다음 문제가 있었다.
역할 정보를 잃을 수 있다. purge 하면 행이 지워진다. 그래서 다시 만들 때 필요한 역할·서버·작업 공간을 purge 전에 따로 적어 두어야 했다.
codex purge 가 두 번 거부됐다 (exit 4).
pane 은 이미 닫혔다.
codex 0.165 의 공용 백그라운드 서버(codex app-server, codex 데몬이 관리하고 MAM 프로세스가 아니다)가 TUI 가 끝난 뒤에도 rollout 파일을 열어 두고 있었다.
그런데 거부 안내(lib_py/agents/base.pyin_use_hints)는 "명령줄에 ID 가 있는 프로세스를 ps | grep 으로 찾으라" 고만 한다. 파일을 연 프로세스는 이 방법으로 찾을 수 없다. conversation_in_use 가 판정에 쓰는 lsof 결과를 안내에 보여 주지 않기 때문이다.
그 app-server 에 TERM 을 보내자 파일을 놓았고, purge 가 통과했다.
purge 뒤에 남는 것:
codex: ~/.codex/tui-thread-reference-capabilities/<uuid>. codex delete 도, codex 어댑터의 purge_artifacts 도 지우지 않는다. WARN residual 로 출력된다.
grok: ~/.grok/memory-v2/workspaces/<작업 공간>/ 의 메모리 노트. 대화 ID 가 이름에 든 파일이 있고, 새 grok 이 이 메모리를 다시 읽을 수 있다. 이번에는 남겨 두었다.
제안: multi-agent-mux-reset 스킬
상주 에이전트의 맥락을 비우는 절차를 스킬 하나로 묶는다. 새 로직은 최소로 하고, 기존 stop(--purge-conversation) 과 create 를 순서대로 부른다.
대상
레지스트리 행 가운데 pane.cwd 가 제어 루트인 것만 고른다.
worktree 에서 일하는 creator(pane.cwd 가 worktree)는 빠진다.
오케스트레이터는 행이 아니므로(orchestrator_uuids) 대상이 아니다.
stopped 행도 대상에 넣을지 정한다(아래 "정할 것").
사전 확인 — 하나라도 해당하면 아무것도 바꾸지 않고 거부한다. #72 의 사전 확인과 입장 잠금을 그대로 쓴다.
열린 잡
살아 있는 루프 표식
진행 중인 업데이트
확인 절차
purge 는 되돌릴 수 없으므로 --yes 없이는 실행하지 않는다.
--dry-run 은 대상과 다시 만들 사양만 출력한다.
순서와 재실행
먼저 대상 행마다 이름, 에이전트, 역할, herdr 서버, herdr 작업 공간을 .mam 아래 사양 파일에 원자적으로 쓴다.
그다음 에이전트마다 purge 하고 바로 create 한다.
중간에 실패하면 멈춘다. 다시 실행하면 사양 파일을 읽어, 아직 만들지 않은 것부터 이어 간다.
모두 끝나면 사양 파일을 지운다.
purge 가 거부될 때 (exit 4)
그 에이전트는 건너뛰고 행과 대화를 그대로 둔다.
대화 파일을 쥔 프로세스(pid, 명령줄)를 출력한다.
외부 프로세스(예: codex app-server)는 종료하지 않는다.
결과: 에이전트마다 새 대화 ID 가 행에 기록됐는지, 이전 ID 와 다른지 표로 출력한다.
함께 고칠 것:
purge 거부 안내:in_use_hints 가 lsof 로 찾은 프로세스(pid, 명령줄)를 함께 보여 준다.
codex 어댑터:purge_artifacts 가 tui-thread-reference-capabilities/<uuid> 도 지운다.
정할 것
onboarding 대기: 이번에는 에이전트마다 1351초, 넷을 순서대로 하면 34분 걸렸다. 병렬로 만들 수는 있다. 하지만 같은 폴더의 같은 종류 에이전트는 #63 규칙 때문에 어차피 순서대로 기다린다. 순서대로 할지 정한다.
grok 메모리:~/.grok/memory-v2/workspaces/<작업 공간>/ 를 비우는 옵션을 둘지 정한다. 기본은 두지 않는 쪽을 제안한다.
stopped 행: 대상에 넣을지 정한다. 넣는다면 다시 만든 뒤 stopped 로 되돌릴지도 정한다.
관련
#31 (purge 범위), #40 (자동 ID 등록), #63 (같은 폴더의 같은 종류 에이전트), #72 (사전 확인·입장 잠금)
버전 번호와 VERSIONS.md 는 릴리스 때 정한다.
## 배경
리뷰어 같은 상주 에이전트는 이슈를 여러 개 거치면 대화 맥락이 너무 커진다. 맥락을 비우려면 지금은 손으로 다음 순서를 밟아야 한다.
1. 대상 행을 고른다.
2. 열린 잡이 없는지 확인한다.
3. 하나씩 `stop --purge-conversation --yes` 를 한다.
4. 같은 이름, 에이전트, 역할, 서버, herdr 작업 공간으로 다시 create 한다.
5. 새 대화 ID 가 행에 기록됐는지 확인한다.
v4.12.0 에서 리뷰어 4개(claude·agy·grok·codex)를 이렇게 다시 만들어 보니 다음 문제가 있었다.
- **역할 정보를 잃을 수 있다.** purge 하면 행이 지워진다. 그래서 다시 만들 때 필요한 역할·서버·작업 공간을 purge 전에 따로 적어 두어야 했다.
- **codex purge 가 두 번 거부됐다 (exit 4).**
- pane 은 이미 닫혔다.
- codex 0.165 의 공용 백그라운드 서버(`codex app-server`, codex 데몬이 관리하고 MAM 프로세스가 아니다)가 TUI 가 끝난 뒤에도 rollout 파일을 열어 두고 있었다.
- 그런데 거부 안내(`lib_py/agents/base.py` `in_use_hints`)는 "명령줄에 ID 가 있는 프로세스를 `ps | grep` 으로 찾으라" 고만 한다. 파일을 연 프로세스는 이 방법으로 찾을 수 없다. `conversation_in_use` 가 판정에 쓰는 `lsof` 결과를 안내에 보여 주지 않기 때문이다.
- 그 app-server 에 TERM 을 보내자 파일을 놓았고, purge 가 통과했다.
- **purge 뒤에 남는 것:**
- codex: `~/.codex/tui-thread-reference-capabilities/<uuid>`. `codex delete` 도, codex 어댑터의 `purge_artifacts` 도 지우지 않는다. `WARN residual` 로 출력된다.
- grok: `~/.grok/memory-v2/workspaces/<작업 공간>/` 의 메모리 노트. 대화 ID 가 이름에 든 파일이 있고, 새 grok 이 이 메모리를 다시 읽을 수 있다. 이번에는 남겨 두었다.
## 제안: `multi-agent-mux-reset` 스킬
상주 에이전트의 맥락을 비우는 절차를 스킬 하나로 묶는다. 새 로직은 최소로 하고, 기존 stop(`--purge-conversation`) 과 create 를 순서대로 부른다.
1. **대상**
- 레지스트리 행 가운데 `pane.cwd` 가 제어 루트인 것만 고른다.
- worktree 에서 일하는 creator(`pane.cwd` 가 worktree)는 빠진다.
- 오케스트레이터는 행이 아니므로(`orchestrator_uuids`) 대상이 아니다.
- `stopped` 행도 대상에 넣을지 정한다(아래 "정할 것").
2. **사전 확인** — 하나라도 해당하면 아무것도 바꾸지 않고 거부한다. #72 의 사전 확인과 입장 잠금을 그대로 쓴다.
- 열린 잡
- 살아 있는 루프 표식
- 진행 중인 업데이트
3. **확인 절차**
- purge 는 되돌릴 수 없으므로 `--yes` 없이는 실행하지 않는다.
- `--dry-run` 은 대상과 다시 만들 사양만 출력한다.
4. **순서와 재실행**
- 먼저 대상 행마다 이름, 에이전트, 역할, herdr 서버, herdr 작업 공간을 `.mam` 아래 사양 파일에 원자적으로 쓴다.
- 그다음 에이전트마다 purge 하고 바로 create 한다.
- 중간에 실패하면 멈춘다. 다시 실행하면 사양 파일을 읽어, 아직 만들지 않은 것부터 이어 간다.
- 모두 끝나면 사양 파일을 지운다.
5. **purge 가 거부될 때 (exit 4)**
- 그 에이전트는 건너뛰고 행과 대화를 그대로 둔다.
- 대화 파일을 쥔 프로세스(pid, 명령줄)를 출력한다.
- 외부 프로세스(예: codex app-server)는 종료하지 않는다.
6. **결과**: 에이전트마다 새 대화 ID 가 행에 기록됐는지, 이전 ID 와 다른지 표로 출력한다.
함께 고칠 것:
- **purge 거부 안내:** `in_use_hints` 가 `lsof` 로 찾은 프로세스(pid, 명령줄)를 함께 보여 준다.
- **codex 어댑터:** `purge_artifacts` 가 `tui-thread-reference-capabilities/<uuid>` 도 지운다.
## 정할 것
- **onboarding 대기:** 이번에는 에이전트마다 13~51초, 넷을 순서대로 하면 3~4분 걸렸다. 병렬로 만들 수는 있다. 하지만 같은 폴더의 같은 종류 에이전트는 #63 규칙 때문에 어차피 순서대로 기다린다. 순서대로 할지 정한다.
- **grok 메모리:** `~/.grok/memory-v2/workspaces/<작업 공간>/` 를 비우는 옵션을 둘지 정한다. 기본은 두지 않는 쪽을 제안한다.
- **`stopped` 행:** 대상에 넣을지 정한다. 넣는다면 다시 만든 뒤 `stopped` 로 되돌릴지도 정한다.
## 관련
- #31 (purge 범위), #40 (자동 ID 등록), #63 (같은 폴더의 같은 종류 에이전트), #72 (사전 확인·입장 잠금)
- 버전 번호와 VERSIONS.md 는 릴리스 때 정한다.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
배경
리뷰어 같은 상주 에이전트는 이슈를 여러 개 거치면 대화 맥락이 너무 커진다. 맥락을 비우려면 지금은 손으로 다음 순서를 밟아야 한다.
stop --purge-conversation --yes를 한다.v4.12.0 에서 리뷰어 4개(claude·agy·grok·codex)를 이렇게 다시 만들어 보니 다음 문제가 있었다.
codex app-server, codex 데몬이 관리하고 MAM 프로세스가 아니다)가 TUI 가 끝난 뒤에도 rollout 파일을 열어 두고 있었다.lib_py/agents/base.pyin_use_hints)는 "명령줄에 ID 가 있는 프로세스를ps | grep으로 찾으라" 고만 한다. 파일을 연 프로세스는 이 방법으로 찾을 수 없다.conversation_in_use가 판정에 쓰는lsof결과를 안내에 보여 주지 않기 때문이다.~/.codex/tui-thread-reference-capabilities/<uuid>.codex delete도, codex 어댑터의purge_artifacts도 지우지 않는다.WARN residual로 출력된다.~/.grok/memory-v2/workspaces/<작업 공간>/의 메모리 노트. 대화 ID 가 이름에 든 파일이 있고, 새 grok 이 이 메모리를 다시 읽을 수 있다. 이번에는 남겨 두었다.제안:
multi-agent-mux-reset스킬상주 에이전트의 맥락을 비우는 절차를 스킬 하나로 묶는다. 새 로직은 최소로 하고, 기존 stop(
--purge-conversation) 과 create 를 순서대로 부른다.pane.cwd가 제어 루트인 것만 고른다.pane.cwd가 worktree)는 빠진다.orchestrator_uuids) 대상이 아니다.stopped행도 대상에 넣을지 정한다(아래 "정할 것").--yes없이는 실행하지 않는다.--dry-run은 대상과 다시 만들 사양만 출력한다..mam아래 사양 파일에 원자적으로 쓴다.함께 고칠 것:
in_use_hints가lsof로 찾은 프로세스(pid, 명령줄)를 함께 보여 준다.purge_artifacts가tui-thread-reference-capabilities/<uuid>도 지운다.정할 것
51초, 넷을 순서대로 하면 34분 걸렸다. 병렬로 만들 수는 있다. 하지만 같은 폴더의 같은 종류 에이전트는 #63 규칙 때문에 어차피 순서대로 기다린다. 순서대로 할지 정한다.~/.grok/memory-v2/workspaces/<작업 공간>/를 비우는 옵션을 둘지 정한다. 기본은 두지 않는 쪽을 제안한다.stopped행: 대상에 넣을지 정한다. 넣는다면 다시 만든 뒤stopped로 되돌릴지도 정한다.관련