remote-access — 작업 규칙

규칙(항구적 판단 기준)만 여기. 상태·이력은 handoff.md. 전역 원격접속 규칙은 seedchain/rules/remote.md가 단일 출처.

🆕 신규

[코디] 🔑26.10.23(금) 「클로드·VS Code 작동 안 함」 → 4종 일괄 최신화로 doctor 8/8 — 원인 = 확장 판 불일치(사무실 2.1.295 / 서버 2.1.296) + 미니 원격 exthost 힙 고갈 흔적. 결과 = CLI·확장 2.1.309(미니 로컬·미니 서버·사무실 로컬) · VS Code 1.143.1(양쪽) · Desktop 3.6556.1(양쪽, 미니는 2.19675 로 크게 묵어 있었다) · 사무실 npm CLI 는 2.1.129 였다. 절차: ①npm CLI = 잠긴 exe 2개 _claude-old-<판>\ 로 move 후 npm i -g(사무실도 같은 수법) ②Desktop = 받은 msix 를 SSH 세션에서 그대로 Add-AppxPackage -ForceApplicationShutdown 해도 된다(사용자 세션 앱이 닫히니 끝나면 schtasks /IT 로 explorer shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude 재기동) ③VS Code 본체 = new_Code.exe·updating_version 이 있으면 자체 업데이터(CodeSetup-stable-*)가 Code 종료만 기다리는 중 → 세션1(schtasks /IT+숨김 vbs)에서 taskkill /IM Code.exe(hot exit)→잔여 /F→CodeSetup 사라질 때까지 대기→무음 설치(/VERYSILENT /MERGETASKS=!runcode)→재기동. 스크립트 = C:\dev\_work\vscup\vsc_update.cmd·vsc_update.vbs. 본체 갱신 뒤 remote-ssh 0.126.0 pinned=True 유지 확인됨. ⚠wscript 에 인자 넘겨 cmd 를 부르는 vbs 는 따옴표가 깨져 결과 1(무로그) — 경로를 vbs 옆 고정으로.
[코디] 🔴26.10.13(화) [페페] 「터미널 방식 원복 → VS Code 클로드 확장 사용으로」 — 아래 «에이전트 화면 기본화»를 전부 되돌렸다. 미니PC C:\dev\.vscode\tasks.json·C:\Users\delix\.vscode-server\data\Machine\settings.json·C:\Users\delix\AppData\Roaming\Code\User\settings.json = .bak-20261013 복원, 사무실PC keybindings.json = 백업 복원(ctrl+alt+a 제거), 사무실PC settings.json 에서 task.allowAutomaticTasks 만 삭제(복원 전 사본 .bak-20261013-revert). 터미널 글꼴 분리(Cascadia Mono)는 무해해서 유지. claude --bg 데몬 경로는 기록만 남고 기본 사용 아님.
[코디] 26.10.13 사무실PC editor.fontFamily=굴림 → 터미널도 굴림이라 claude TUI 깨짐. terminal.integrated.fontFamily 를 Cascadia Mono 로 분리(백업 .bak-20261013-font).
[코디] 🔑26.10.13(화) 에이전트 화면 기본화(①안, 페페 승인) — 사무실PC 원격 창을 열면 아래 터미널에 claude agents 가 자동으로 뜨고, Ctrl+Alt+A 를 누르면 같은 화면이 편집기 탭으로 열린다. 설정 위치: 태스크 = C:\dev\.vscode\tasks.json 「클로드 에이전트 화면」(runOn: folderOpen · instancePolicy: silent · 절대경로 C:\Users\delix\AppData\Roaming\npm\node_modules\@anthropic-ai\claude-code\bin\claude.exe agents --permission-mode bypassPermissions). 자동 실행 허용 = 사무실PC %APPDATA%\Code\User\settings.json task.allowAutomaticTasks:"on". ⚠이 값은 application 범위(1.140 본체 scope:1)라 원격 Machine 설정에 두면 무시된다. 기본값은 "off" 지만 사용자값이 없으면 창마다 «허용?» 알림이 1회 뜬다. 그래서 미니PC 로컬 C:\Users\delix\AppData\Roaming\Code\User\settings.json 에는 "off" 를 명시했다(노트북은 미설정이라 알림 1회). 프로필 «Claude Agents» = 미니PC C:\Users\delix\.vscode-server\data\Machine\settings.json(원격 창 전용). 단축키 = 사무실PC keybindings.json ctrl+alt+a → workbench.action.terminal.newWithProfile {profileName, location:"editor"}, when remoteName=='ssh-remote'. 태스크 터미널은 위치를 지정할 수 없다(terminal.integrated.defaultLocation 을 따르므로 자동분은 아래 패널에 뜬다). 백업 = 각 파일 .bak-20261013. 실측(26.10.13 09:03~09:06 KST): --bg 시험 세션 → ssh -tt 로 attach 한 뒤 20초 만에 강제로 끊음 → 세션이 계속 돌아 exit 0 으로 완주. 데몬 체인 = claude.exe ← bg-pty-host ← daemon run --origin transient ← WmiPrvSE ← svchost(DcomLaunch)이고 VS Code 서버 트리와 교집합이 없다. 데몬은 클라이언트가 없으면 5초 뒤 스스로 내려간다. 사용법: 시작 = 에이전트 화면에서 새 세션 · 조작 = 목록에서 골라 붙기 · 빠져나오기 = ←(세션 유지) · 중지 = 목록에서 하거나 claude stop <id>. ⚠ssh -tt 시험에는 stdin 을 열어 둬야 한다((sleep N) | ssh -tt …). /dev/null 이면 TUI 가 즉시 끝난다.
[코디] 🔑26.10.13 VS Code 창을 닫아도 계속 도는 세션 = claude --bg(CLI 2.1.288) — 백그라운드 서비스가 WMI(WmiPrvSE) 밑의 독립 데몬으로 떠서 SSH·VS Code 서버 트리 밖에 산다. 실측: SSH(Session 0)에서 cd /d C:\dev && claude --bg --name bgtest-1013 "…sleep 180…" 실행 → SSH 종료 → 3분 작업 완주(BGTEST DONE). 관리 = claude agents·attach <id>·logs <id>·stop <id>. 기존 대화를 넘기려면 claude --bg --resume <세션ID>(실행 중이면 사본으로 시작). ⚠신뢰 안 된 폴더(%TEMP%)에선 거부 → C:\dev 에서 띄운다. 데몬도 Session 0 이라 GUI 작업은 불가하다. 활용 방식은 페페 결정 대기.
[코디] 🔑26.10.13 VS Code 원격 세션이 서버 재시작·창 닫기에 끊기는 이유 = 클로드 프로세스가 원격 exthost 의 자식이다(실측 체인 claude.exe ← exthost node ← server node ← code-<커밋>.exe ← sshd). 리모트컨트롤은 그 프로세스를 보는 창일 뿐이라, 프로세스가 죽으면 같이 끊긴다. 사무실 창을 정상으로 닫으면 약 2초 뒤 exthost 가 exit 0 으로 내려간다(10.13 08:13:26 graceful disconnect → 08:13:28). 반면 claude remote-control --name poin-local 호스트 세션(Session 1, conhost 밑)은 VS Code 와 무관하다. 08:15 서버 kill 뒤에도 10.12 21:09·21:17, 10.13 00:16 세션이 살아 있었다. 서버가 굳어도 기존 exthost 세션은 계속 돈다(막히는 건 새 기동뿐). 해결안(페페 결정 대기) = ①굳은 서버는 세션이 전부 유휴일 때만 kill(유휴 판단 = transcript 10분+ 무변화) ②무인 장시간 작업은 RC 호스트 세션으로 돌린다 ③(검증 필요) Remote-SSH 호스트 별칭 + serverInstallPath 분리로 굳은 서버를 남긴 채 새 서버를 연다.
[코디] 🔑26.10.13(화) 정정: exthost 0xC0000142 는 힙 크기 문제가 아니다. heapwatch(C:\dev\_work\vscode-exthost\heapwatch.csv, 10.2~10.13 1057행) 전체에서 Session 0 힙 커밋 최대 0.7%, 실패 순간도 10.9 22:56=68/16384KB · 10.13 08:11=52/16384KB, 프로세스 수 74개 고정 → 누수·고갈 아님. 서버별 exthost 기동 순서(remoteagent.log): 9.30 서버 oooXXXX(첫 실패 10.2 08:19, 기동 약 46h 후) · 10.7 서버 oXXXXXXXXXXX(10.9 22:49, 약 49h) · 10.12 서버 oXXXXXXX(10.13 08:13, 약 24h) · 나머지 서버 7개 실패 0. 즉 서버가 수십 시간 뒤 «새 프로세스 user32 초기화 실패» 상태로 굳어 그 서버에선 이후 기동이 전부 실패하고 새 서버면 풀린다. 굳는 계기 미확인(후보: 밤사이 절전·Modern Standby). SharedSection 상향은 효과 없는 레버. 처방 = kill 후 새 서버, 항구책 = 서버 자동 재시작 검토(페페 결정 대기).
[코디] 26.10.13(화) 08:15 KST 사무실PC→미니PC VS Code 원격 실패 = Session 0 힙 고갈 재발(→ 같은 날 정정: 힙 고갈 아님, 위 줄)(exthost 0xC0000142 21회, 서버 Stable-2a59476c 1.141.0 node 7804·13652+cmd 5276, 26.10.12 07:47 기동→약 24h). SharedSection 16384 적용 후에도 24h 고갈 재발 → 응급 처방(el.py taskkill /F 세 PID) 유효, 항구책 = 서버 수명 제한 검토(미착수). 로그 C:\Users\delix\.vscode-server\data\logs\20261012T074750\remoteagent.log.
[코디] 🔑26.10.10 kbdlock A3 x64 주입 실패 = «x86·x64 전역 WH_KEYBOARD 훅 동시 설치» 충돌이었다(해결). 최소 probe DLL 로 좁혔다: x64 훅 «단독»이면 64비트 표적(keytarget64)에 정상 주입(DllMain·프로시저 실행, F24 차단) · 그런데 kbdhost32(x86 전역 훅)가 «같이» 떠 있으면 같은 x64 DLL 이 64비트 표적에 주입조차 안 된다(DllMain 0회). 즉 DLL·툴체인·권한 문제 아님(MSVC 불필요). 처방 = 기본 x64 훅만 띄운다(cover_x86=False 기본) — pepe 실사용 앱(크롬·VS Code·탐색기·최신 메모장)은 전부 64비트라 이걸로 충분. 32비트 앱까지 막아야 할 때만 kbdlock.json "cover_x86": true(그 순간 x64 주입이 깨질 수 있음을 감수). 검증 = selftest ·OK(x64 강제차단 f24=0·HELLO bits=64·해제후 통과). 상주 재가동(kbdlock Enabled). 1차 실패 원인은 별도(메시지번호, 아래).
[코디] (옛 기록) 26.10.10 kbdlock A3 1차 조사 — x64 훅 미발화로 보였던 건 위 충돌 때문. x86 훅은 32비트 앱에 정상 주입·질의·차단·해제까지 끝까지 확인(HELLO 핑 bits=32 수신, block 카운터 상승, keytarget32 미입력). 같은 소스 x64 DLL 은 64비트 표적(keytarget64)이 키를 받아 메시지펌프를 돌려도 훅 프로시저가 아예 안 돈다(HELLO bits=64 0건) — 호스트 exe(kbdhost64)로 걸든 64비트 pythonw in-proc 로 걸든 동일. ctypes.WinDLL LoadLibrary 로는 로드됨, import 테이블은 x86/x64 동일(user32·kernel32·api-ms-win-crt-). 크롬·VS Code·최신 메모장이 다 64비트라 이 상태로는 실사용 불가. 다음 후보 = ①다른 툴체인(MSVC cl/clang-cl)으로 x64 DLL 재빌드해 주입되는지 ②알려진 정상 x64 훅 DLL 로 이 노트북에서 x64 WH_KEYBOARD 주입 자체가 되는지(보안툴·정책 배제) ③주입 지연 가능성(장시간 타이핑). 검증 철칙 = 판정함수 직접호출로 «통과»라 하지 말 것 — 다른 프로세스에서 HELLO·차단을 본 것만 통과*(selftest 가 그래서 오판했었다). 상주는 중지(kbdlock Disabled). 측정 원본 = selftest 로그·q/hello 카운터.
[코디] 26.10.10 kbdlock 1차 실기 실패 근본원인 = 질의 메시지번호 불일치(서버 WM_USER+0x51=0x451 vs DLL WM_APP+0x51=0x8051) → 모든 질의 fail-open 통과. + 훅이 상주 자기 프로세스에만 로드돼 대상 앱엔 없었다. 수정 = 상수 단일 출처 C:\dev\tools\kbdlock\native\kbdshared.h(서버 py 와 동일값), 호스트 exe 로 훅 설치, UIPI ChangeWindowMessageFilterEx(MSGFLT_ALLOW), 강제차단 시험모드(--force-lock), 질의 카운터+HELLO 핑.
[코디] 26.10.10 키보드별 키 차단 해법 = A3 = Raw Input 장치판정 + 전역 WH_KEYBOARD 네이티브 DLL. LL 훅·PnP 둘 다 불가(아래 2건)라 이 길뿐. DLL(WH_KEYBOARD, x64/x86 각각)이 각 앱의 키 메시지 꺼낼 때 상주 서버 창에 SendMessageTimeout(150ms·ABORTIFHUNG)으로 질의 → 서버가 Raw Input(INPUTSINK) 장치 핸들로 내장/BT 판정해 잠김+내장일 때만 1(차단), 그 외·타임아웃·무응답은 통과(fail-open). 64비트 앱=서버 프로세스가 훅, 32비트 앱=별도 32비트 호스트 exe. 컴파일러 = 미니PC python -m pip install ziglang(zig cc -target x86_64/x86-windows-gnu -shared), 노트북엔 바이너리만 배포 + DLL 에 icacls … /grant *S-1-15-2-1:(RX)(AppContainer 스토어앱). 서버 죽으면 훅은 프로세스 종료로 자동 해제=자동 풀림. WM_INPUT↔질의 경합은 Matcher(스캔·E0·up 짝짓기)로 흡수하고 질의 때 큐의 WM_INPUT 을 먼저 drain. 실물·검증 = C:\dev\tools\kbdlock\(README·selftest 13/13). A3 한계 = 시스템 단축키·앱이 직접 읽는 수식키 상태는 못 막음.
[코디] 26.10.10 키보드별 키 차단은 LL 훅으로 안 된다 — LL 훅이 막은 키는 Raw Input(WM_INPUT)이 아예 안 생기고, 통과 키도 Raw Input 이 훅 «뒤»에 온다(poin-lap 주입 실측 0/40·0/40, 원본 C:\dev\tools\kbdlock\probe_order.result.json). 가능한 길 = WH_KEYBOARD 전역 네이티브 DLL(컴파일러 필요 — 미니PC·노트북 둘 다 없음) 또는 PnP 장치 비활성. · schtasks /create /it 작업은 노트북 배터리 상태면 Queued 로 멈춘다 → -AllowStartIfOnBatteries(C:\dev\tools\kbdlock\s1run.ps1). · ssh(Session 0)에선 Raw Input 장치 목록이 비어 나온다 → Session 1 에서 잰다.
[코디] 26.10.10 PS/2 내장 키보드(ACPI\LEN0071)는 실시간 비활성 불가 — pnputil /disable-device = 「critical system device」 거부, /force = 즉시 안 꺼지고 재부팅 대기로 Enum\ACPI\LEN0071\…\ConfigFlags=0x1 이 남는다 → pnputil /enable-device 는 already enabled 라며 플래그를 안 지운다(방치 = 재부팅 후 키보드 사망) → 되돌리기는 Enable-PnpDevice -InstanceId … -Confirm:$false(ConfigFlags 0 확인).
[코디] 26.10.10 kbdlock A3 1차 = 실기 실패 — 전역 WH_KEYBOARD DLL 이 대상 앱에 안 들어감(tasklist /m kbdhook64.dll = 자기 프로세스뿐) + 질의 메시지 번호 불일치(서버 WM_USER+0x51 ↔ DLL WM_APP+0x51). selftest 13/13 은 판정 함수 직접 호출이라 못 잡음 → 검증은 tasklist /m <dll> 로 대상 앱 로드 + 다른 프로세스에서 «차단» 실측까지. 상주는 내리고 예약작업 kbdlock 비활성(Disabled) 상태.
[코디] 26.10.9 VS Code 본체를 올린 뒤엔 Remote-SSH 판을 한 번 더 본다 — 노트북 본체 1.141.0 갱신 7분 뒤(VS Code 기동 직후) autoUpdate "off" 인데도 0.128.0 이 재설치됐다(그때 0.126.0 은 extensions.json pinned=False). 설치 직후 안전장치 검사로는 못 잡는다. 처방 = code --install-extension ms-vscode-remote.remote-ssh@0.126.0 --force(VS Code 가 pinned=True 기록) + 0.128.0 폴더 DISABLED- 개명 + extensions.json pinned 확인.
[코디] 26.10.7 꺼져 있는 원격 PC 에 작업을 «예약»하려면 = 미니PC 감시 예약작업(10분 · pythonw · 온라인 판정 = tailscale 줄 + ssh -o BatchMode=yes 둘 다)으로 켜지는 순간 scp→sha256 대조→schtasks /Create /XML 한다(사람이 「켜지면 돌려라」를 기억하는 방식은 1003 처럼 미등록으로 끝난다). ⚠InteractiveToken 작업 /Run 은 로그온이 없으면 안 돈다 → 감시기가 explorer(Session≥1) 유무로 로그온 판정. 쓰는 창 보호 = 즉시 실행은 -NoKill(실행 순간 Code 가 떠 있으면 확장만). 실물 = C:\dev\_work\vscode-lap\update-1007\lap_watch.py.
[코디] 26.10.7 Git Bash 에서 code --extensions-dir C:\\Users\\... 처럼 백슬래시 경로를 주면 code sh 래퍼가 \ 를 먹어 C:Usersdelix.vscode-serverextensions 로 바뀌고 VS Code 설치폴더 아래 엉뚱한 폴더에 깔린 뒤 「successfully installed」 를 띄운다(대상 폴더 무변화). → 경로는 슬래시(C:/Users/...) 로 주고 설치 후 --list-extensions --extensions-dir 로 판 재확인.
[코디] 26.10.7 ssh(관리자 승격 토큰)로 C:\ProgramData\<폴더> 에 만든 파일은 소유 = Administrators, Users 는 RX 뿐 → /RL LIMITED 대화형 예약작업이 그 파일에 append 를 조용히 실패한다(새 파일 생성은 됨). 드라이런 로그를 ssh 로 먼저 만들면 본실행 로그가 통째로 빠진다 → 로그는 예약작업이 처음 만들게 두거나 %LOCALAPPDATA% 에 둔다.
[코디] 26.10.3 VS Code가 업데이트를 미리 받아두면 CodeSetup-stable-* 설치기가 Code 종료를 기다리며 떠 있다 → 끄고 별도 설치기를 바로 돌리면 둘이 동시에 돈다. 그 프로세스 종료 대기 후 판 재확인(표시 = 설치 폴더 updating_version·new_Code.exe).
[코디] 26.10.3 Claude Desktop MSIX 는 -DeferRegistrationWhenPackagesAreInUse 로도 실행 중 앱이 재시작된다(무중단 갱신 불가). 판 확인은 winget 말고 redirect URL.
[코디] 26.10.3 npm 태그 stable=2.1.285 / latest=2.1.288 — CLI·확장은 latest 기준으로 맞춘다.
[코디] 26.10.3 VBScript 는 변수·상수 이름 대소문자 무구분(pyw/PYW 충돌). 실행 없이 문법검증 = 사본 맨 앞 WScript.Quit 후 cscript.
[코디] 🔑26.10.2 — 데스크톱 힙 사용량은 «재는 API 없음»이 아니다: 힙 섹션이 그 데스크톱의 GUI 프로세스마다 읽기전용으로 매핑돼 있다. 크기 = heap_kb+4KB(8192→8196KB · WinSta0 20480→20484KB) MEM_MAPPED 영역 → VirtualQueryEx MEM_COMMIT 합 = 힙 커밋(실사용 상한, 100%=고갈). 실측 = 탐색기 1348/20484KB · 새 원격 서버 28/8196KB(멤버 3개 동일 = 공유 섹션). 읽기만이라 오염 0. 도구 = C:\dev\tools\session0-heapwatch\heapwatch.py. ⚠GetGuiResources 는 다른 세션 프로세스엔 0 → Session 0 에서(SYSTEM 예약작업) · ⚠SYSTEM 도 Service-0x0-<LUID>$ 를 WINSTA_ENUMDESKTOPS·READATTRIBUTES 로 콕 집어 열면 err5 → MAXIMUM_ALLOWED · ⚠Session 1 프로세스 토큰 LUID 로 Service-0x…$ 이름을 만들면 틀린다(그들은 WinSta0) — 세션 0 걸러서만.
[코디] 🔑26.9.30 Session 0 GUI 누수 3겹 장치 — ①C:\Users\delix\.bashrc = SSH 셸만 askpass·GCM 프롬프트 차단(코디 Bash=bash -c -l 이라 즉시 · Session 1 무변경) ②C:\dev\tools\session0guard.py = 카톡 창찾기·기동 함수에서 Session 0 이면 exit 3(새 카톡 스크립트도 require_desktop() 을 거친다) ③\Cody\session0-reaper(SYSTEM 30분) = 부모 죽은 30분+ git-askpass·KakaoTalk 등 종료(C:\dev\tools\session0-reaper\). ⚠SSH 셸의 GCM 은 wincredman 을 못 쓴다 → 원격 세션 https push 는 실패가 정상(SSH remote 나 Session 1 경유).
[코디] ⛒Session 0(SSH/원격) Bash에서 GUI 띄우는 명령(git https 자격·카톡) 금지 — 타임아웃 시 고아로 남아 데스크톱 힙 누수(26.9.30).
[코디] 🔴26.9.30 — 데스크톱 힙 고갈 재발(3072KB 로도 22시간) + «5분 안 재접속» 함정. 서버가 26.9.29 09:27 ~ 26.9.30 07:44 살았고(원격 세션 7개), 07:47 부터 새 exthost 가 전부 0xC0000142. ⛒원격 창을 닫았다 5분 안에 다시 열면 같은(고갈된) 서버에 또 붙는다 — 서버는 마지막 연결이 끊기고 5분 뒤(ServerLifetime: all consumers inactive)에야 내려간다(그날 07:47·07:51·07:53·07:54 네 번 다 같은 서버). 26.9.22 「창을 닫았다 다시 연다」 응급처방에 «5분 넘게 기다렸다가» 가 빠져 있었다. 실측 = SSH 연결마다 Service-0x0-<LUID>$ 윈도스테이션이 새로 생기고 UOI_HEAPSIZE=레지스트리 세 번째 값(도구 = 원격에서 GetProcessWindowStation+GetUserObjectInformationW(UOI_HEAPSIZE)). 처방 = 3072→8192(코덱스 상의: x64 Win11 은 16384 까지 실무 안전, 20480+ 비권장) · C:\dev\_work\vscode-exthost\heapfix-8192.ps1(el.py SYSTEM) · 되돌리기 값 = 같은 폴더 SubSystems.Windows.bak-20260930.txt · 재부팅해야 먹는다. 판정 자동화 = doctor 8번 줄.
⚠고갈된 서버에서 원격 창 «Update» 를 누르면 서명검증 프로세스도 0xC0000142 로 죽는다(Extension signature verification result ... UnknownError. Internal Code: 3221225794) → «그래도 설치»(donotVerifySignature:true)로 서버만 새 판이 된다 = 판 불일치가 겹친다. 무결성 확인법 = 서명검증된 다른 PC 사본과 파일별 SHA-256 대조(package.json 은 __metadata 만 다르다).
⏳누수(고아 셸 누적)인지 동시 프로세스 수 때문인지는 아직 모른다 — 코덱스 권고 = 새 서버 기동 직후·매시간 그 윈도스테이션의 claude/node/bash/conhost 수·핸들·USER 객체 수를 CSV 로. 같은 세션 수에서 계속 늘면 누수.
[코디] 🔑26.9.24 — 미니PC(집 회선)에서 DB 는 «직결 말고 터널/tailnet» — 운영 RDS=127.0.0.1:13306·테스트=127.0.0.1:13307(둘 다 C:\dev\tools\rdstunnel SSM, SG 무변경) · imos MSSQL=100.101.40.17:64910(사무실 공인IP 경유 금지 — 회선 바뀌면 끊김). DBeaver 설정은 DBeaver 를 끈 뒤 C:\dev\tools\rdstunnel\dbeaver_conns.py 로 고친다(켜진 채 고치면 종료 때 덮어씀) · ⚠「새 버전 나왔습니다」 모달이 떠 있으면 WM_CLOSE(=taskkill 무/F)가 무시된다 → 그 모달의 닫기 버튼에 BM_CLICK 후 종료(SendKeys 금지).
[코디] 🔴26.9.24 — 「기본 모델·노력도 바꿨는데 안 먹는다」 = 프로젝트 .claude\settings.local.json 이 전역을 덮는다. 미니PC는 전역 ~/.claude/settings.json 이 medium 이었는데 C:\dev\.claude\settings.local.json 의 "effortLevel": "xhigh" 가 우선 적용되고 있었다. 기본값을 바꿀 땐 전역 + 작업폴더 .claude\settings*.json 둘 다 본다. [페페] 기본 = claude-opus-5-5 · medium(미니PC 반영 26.9.24, 사무실PC 는 26.9.23 완료).
[코디] ⛒26.9.23 — claude remote-control --help 는 도움말을 찍고도 안 끝난다(120초 타임아웃으로 걸려 있었다). 옵션 확인은 timeout 10 을 붙이거나 백그라운드로 돌리고 남은 pid 를 끈다. 세션 자동 종료 옵션은 없다(--capacity 만 있다) → C:\dev\tools\remote-control\session_reaper.py 가 대신한다.
[코디] 🔁26.9.23 — VS Code 클로드 증상은 playbook.md 맨 위 절이 단일 출처다. 첫 명령 = python C:/dev/tools/vscode-claude-doctor/doctor.py(사무실PC·미니PC 7항목 실측, FAIL 줄이 곧 처방 · --selftest). 규칙 본문을 여기저기 베끼지 말고 그 절만 고친다.
[코디] ⛒26.9.23 금지 — 페페가 쓰고 있는 PC 에 SendKeys/AppActivate GUI 자동화를 걸지 마라. VS Code 에 명령 팔레트를 쳐 넣으려다 그 사이 페페가 엑셀을 만지면 키가 엑셀 셀로 들어간다(실제로 4초 뒤 캡처에서 엑셀이 앞에 있었다 — 입력 흔적은 없었지만 운이었다). 원격 PC 의 GUI 상태 확인은 PrintWindow 로 «그 창만» 찍는다(C:\dev\_work\vscode-office\winshot.ps1 · PW_RENDERFULLCONTENT=2 · 포커스 안 뺏고 가려져 있어도 찍힌다 · 예약작업 CodyWinShot). 전체화면 캡처(CodyShot)는 페페가 뭘 하고 있는지 보는 용도로만.
[코디] 🔑26.9.23 확립 — 클로드 확장의 claudeCode.preferredLocation 값 panel 은 «VS Code 하단 패널」이 아니라 «편집기 탭»이다(enum = sidebar·panel, enumDescription = Sidebar (Right)·Panel (New Tab)). sidebar 로 두면 사이드바 한 칸에서만 열려 세션을 나란히 못 본다 = 「한 번에 한 세션」 증상. 26.9.4 「하단 패널은 안 보인다 → 사이드바로」가 이 오해였다. ⚠확장이 이 값을 자동으로 덮어쓴다 — 사이드바에서 한 번 열면 도로 sidebar. ⚠원격 창에선 미니PC C:\Users\delix\.vscode-server\data\Machine\settings.json 이 사무실PC 사용자 설정을 이긴다 → 두 곳 다 고친다.
탭·창 분리 = claude-vscode.editor.open(새 탭) · claude-vscode.window.open(새 창) · claude-vscode.sidebar.open. 확장 기본 Ctrl+Shift+Esc 는 윈도우가 작업관리자로 먼저 먹어 VS Code 에 안 온다 → 사무실PC C:\Users\poinpc\AppData\Roaming\Code\User\keybindings.json 에 Ctrl+Alt+N·Ctrl+Alt+Shift+N·Ctrl+Alt+S 로 새로 달았다.
[코디] 🔑26.9.23 확립 — 「새 세션 버튼이 내장 클로드로 간다」의 진짜 원인은 확장 판이 아니라 VS Code 1.138 본체의 agent host Claude 다. 판을 아무리 맞춰도(로컬·서버·본체 커밋 전부 일치) 증상은 그대로였다. 처방 = 사무실PC 사용자 설정 2줄 — "chat.agentHost.claudeAgent.enabled": false(내장 Claude 하네스 차단) + "chat.disableAIFeatures": true(내장 채팅 진입점 통째 차단, 안 넣으면 같은 버튼이 Copilot 채팅으로 간다). 창을 Reload 해야 먹는다.
⛒설정 ID 를 공식문서에서 베끼지 마라 — 문서·블로그는 github.copilot.chat.claudeAgent.enabled 라고 쓰는데 1.138 내장 copilot 확장 package.json 엔 그 문자열이 0건이다. 설치된 본체가 단일 출처: …\Microsoft VS Code\<커밋10자>\resources\app\out\vs\workbench\workbench.desktop.main.js 를 정규식으로 훑어 실제 ID 와 판정식을 읽는다(실측 getValue("chat.agentHost.claudeAgent.enabled") !== false = 기본 켜짐).
🔑1.138 설치 레이아웃이 바뀌었다 — 본체 파일이 Microsoft VS Code\<커밋10자>\ 밑으로 내려갔다. 위에서 resources 를 찾으면 「경로 없음」이 뜬다. 그리고 사무실PC PATH 의 code 는 옛 x86 1.32.3(C:\Program Files (x86)\Microsoft VS Code)이 먼저 잡힌다 → 버전·확장 확인은 %LOCALAPPDATA%\Programs\Microsoft VS Code\bin\code.cmd 전체 경로로.
화면 확인은 사무실PC Session 1 에 예약작업(/IT)으로 숨김 .vbs → PowerShell CopyFromScreen 캡처가 제일 싸다(도구 = C:\dev\_work\vscode-office\shot.ps1·shot.vbs, 원격 작업 = CodyShot, 산출 = 사무실PC C:\cody-shot\screen.png).
[코디] 🔴26.9.23 판 불일치 재발 경로 = 원격 창 확장 보기의 «Update» 는 원격(서버) 사본만 올린다(remoteagent.log Installing extension ... "pinned":true,"operation":3). 로컬은 autoUpdate:"off" 라 그대로 → 새 세션 버튼이 내장 Claude(agent host)로 빠진다. 올릴 땐 로컬 code --install-extension anthropic.claude-code@<판> --force 를 같이. 증상 오면 첫 확인 = 서버 ls ~/.vscode-server/extensions | grep claude vs 사무실PC dir %USERPROFILE%\.vscode\extensions(VS Code 본체 커밋은 code --version 둘째 줄 = 서버 cli\servers\Stable-<커밋>). 내장 쪽 차단 스위치 = chat.agentHost.claudeAgent.enabled(VS Code 1.138 코어 설정).
[코디] 🔴「Remote Extension host terminated unexpectedly 3 times」 = 미니PC Session 0 «비대화형 데스크톱 힙» 고갈이다(26.9.22(화) 확립). 판정 한 줄 = ~/.vscode-server/data/logs/<ts>/remoteagent.log 에 Extension Host Process exited with code: 3221225794 — 3221225794 = 0xC0000142 STATUS_DLL_INIT_FAILED, launch 4ms 만에 죽는다(확장 버그가 아니라 프로세스 생성 자체가 실패). 같은 순간 File Watcher (universal) 도 같은 코드로 죽으면 확정.
원인 = vscode-server 는 sshd → cmd → server 로 뜨므로 exthost 가 Session 0(실측 pid 계보). Session 0 비대화형 데스크톱 힙 = HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems\Windows 의 SharedSection 세 번째 값 768KB 뿐인데, 원격 창에서 도는 클로드 세션들이 Bash 껍데기 셸(cmd·conhost·bash)을 계속 만들어 21시간 만에 다 먹었다(26.9.21 07:47 기동 → 26.9.22 07:46~07:48 21회 연속 실패).
⛒시스템 전역 자원 고갈로 오진하지 마라 — 그때 램 49%·커밋 70.7%·Resource-Exhaustion-Detector 이벤트 0건이었다. 데스크톱 힙 고갈은 이벤트 로그에 아무것도 안 남는다. 「새 서버를 띄우면 즉시 정상」이면 전역 자원이 아니라 그 서버 프로세스가 쓰던 힙이다.
처방(항구) = SharedSection=1024,20480,768 → ,3072(26.9.22 적용, C:\dev\_work\vscode-exthost\heapfix.ps1 · el.py SYSTEM · 되돌리기 값 = 같은 폴더 SubSystems.Windows.bak.txt). ⚠재부팅해야 csrss 가 읽는다 — 그 전까진 768 그대로다.
응급(재부팅 전) = Reload Window 가 아니라 원격 창을 닫고 5분 넘게 기다렸다가 다시 연다(서버 프로세스가 새로 떠야 힙이 회수된다 · 5분 안에 열면 같은 서버 — 26.9.30 정정, 위 🆕). 26.9.22 도 서버가 07:52 ServerLifetime: all consumers inactive 로 내려가고 07:53 새로 뜨면서 풀렸다.
[코디] 🔑사무실 공유기(ipTIME 신형 Flutter UI) 는 스크립트로 완전히 조종된다 — 26.9.17 확립. 엔드포인트 POST http://192.168.0.1/cgi/service.cgi, 본문 = {"method":..,"params":..}(jsonrpc·id 넣지 마라). 로그인 = session/login {"id","pw","flush":true} → "done" + efm_session_id 쿠키. ⛒LAN 에서는 캡차를 안 묻는다 — 26.9.16 에 「캡차 때문에 막혔다」고 판정하고 gemini OCR 까지 붙였던 건 오진이었다. -32602 Invalid params 의 진짜 원인 = 캡차를 문자열로 보낸 것(스키마는 captcha:{text,url}). 교훈 = 응답코드가 「Invalid params」면 세션·전송이 아니라 params 스키마를 먼저 의심한다. 스키마 확인법 = /ui/main.dart.js(≈5MB) 를 내려 toJson(X(){return A.O([...])}) 을 읽으면 필드명이 그대로 나온다.
무선WAN = wireless/client/show 의 type=="wan" 항목(band,enable,type,bssid,ssid,authenc,password). 바꿀 때는 show 가 준 dict 를 그대로 되돌려주고 바꿀 키만 얹는다(+commit:true) → SSID·비번이 지워지지 않는다. 유선WAN = network/interface/wan1/info · 물리링크 = port/link/status.
⚠commit:true 응답이 ~12초 걸린다 — urllib 기본/10초 타임아웃이면 무조건 TimeoutError. 45초로 둔다(상태는 실제로 적용되므로 타임아웃을 실패로 오판하면 더 위험).
⚠이 펌웨어엔 WAN failover(유선↔무선 자동전환) 기능이 없다(메서드·i18n 키 전수조사, wan/heartbeat 는 keepalive 다). 「공유기가 알아서 유선으로 돌아오겠지」는 성립하지 않는다.
공유기를 만지는 자동화는 사무실PC 에서 돌린다 — 인터넷이 끊기면 미니PC 는 tailscale 로 사무실에 못 닿는다(공유기는 LAN 이라 사무실PC 에서만 확실히 닿는다). 정본 = C:\dev\tools\officewan-watch\wanfix.py.
[코디] 🔴미니PC VS Code 서버는 사무실PC·노트북 «공용 한 벌»이다 — 한 클라이언트에 맞춰 서버 확장 판을 바꾸면 다른 클라이언트가 깨진다(26.9.17 실측, 아래 26.9.16 처방의 구멍). 26.9.16 노트북(2.1.268→2.1.273)에 맞춰 서버를 2.1.263→2.1.273 으로 올렸더니 사무실PC(로컬 2.1.263) 에서 클로드 아이콘이 VS Code 내장 Copilot Chat 의 Claude(agent host) 로 연결되고 멀티세션이 안 됐다. ⛒서버 판을 바꾸기 전에 붙는 클라이언트 전부의 판을 먼저 본다(사무실PC ssh poinimos01 dir %USERPROFILE%\.vscode\extensions · 노트북 ssh poin-lap 같은 명령 · 오프라인이면 보류) → 판 올리기는 페페 확인 후 세 곳 동시. 오늘 접속 중인 클라이언트 판별 = tailscale status 의 active 줄.
되돌림 재료 = 서버 캐시 VSIX C:\Users\delix\.vscode-server\data\CachedExtensionVSIXs\<id>-<ver>-win32-x64(확장자 없음 → .vsix 로 복사) · 설치 = C:\Users\delix\.vscode-server\cli\servers\Stable-<commit>\server\bin\code-server.cmd --install-extension <vsix> --force(전체 경로로 — cd 후 cmd //c 는 cwd 가 안 넘어가 「명령 없음」). ⚠이 CLI 는 설치를 끝내고도 안 끝난다(180초 타임아웃에 죽였는데 폴더는 완전했다) → 파일 수·크기를 VSIX 와 대조해 판정. ⚠파일 설치는 폴더명이 -win32-x64 없이 · source:"vsix" 로 들어간다 → 원상 복구면 폴더 개명 + extensions.json.bak-* 덮기.
⚠CLI 가 돌고 있는 세션의 옛 판 폴더를 지운다(claude.exe 가 떠 있어도 삭제됨) — 세션은 메모리로 계속 돌지만 서버 재시작 전엔 새 판이 안 뜬다. 재시작 = 원격 클로드 세션 전부 끊김 → 다른 세션이 작업 중이면 시점은 페페.
[코디] 🔑VS Code 원격에서 클로드 아이콘이 사라지면 = 클라이언트·서버 «확장 버전 불일치»다(26.9.16 확정, 26.9.4 사무실PC 미해결건과 같은 원인). 증상 = 원격 창(dev [SSH: poin-mini])에서 액티비티바 클로드 아이콘 자리 자체가 없고 탭 앞 별표·편집기 우상단 버튼도 같이 없다. 확장은 정상 동작한다(패널 열리고 세션 복원됨) — 그래서 「확장이 죽었나」로 헛짚기 쉽다.
원인 = 노트북 로컬 2.1.268 vs 미니PC 원격 2.1.263. 버전이 어긋나면 코드는 원격에서 활성화되는데 UI 기여(viewsContainers·탭 아이콘·editor/title)가 통째로 등록되지 않는다. 노트북은 extensions.autoUpdate:"off"(Remote-SSH 0.126.0 고정 때문)라 시간이 지나면 반드시 어긋난다.
⛒처방 = 양쪽을 같은 판으로. 노트북 code --install-extension anthropic.claude-code@<버전> --force + 미니PC code --extensions-dir C:\Users\delix\.vscode-server\extensions --install-extension anthropic.claude-code@<버전> --force. 구버전 폴더는 DISABLED- 로 개명.
⚠서버 프로세스가 구버전을 물고 있다 — ~/.vscode-server/extensions 를 갈아도 code-<commit>.exe 가 살아 있으면 반영 0. 그 프로세스는 SSH 가 관리자 토큰이라 비관리자 셸의 kill 이 거부된다 → python C:\dev\tools\elevated-runner\el.py "taskkill /F /PID <pid>". 로그 폴더도 새로 안 생기고 같은 logs/<ts>/ 밑에 exthost2·exthost3 로 늘어난다(어느 판이 떴는지는 grep -o "claude-code-2\.1\.[0-9]*" exthostN/remoteexthost.log).
⚠아니었던 것 2개(같은 날 배제) = ①원격 extensions.json 의 위치 항목이 대문자 /C:/·fsPath 없음 → 무관(VS Code CLI 가 원래 그 최소 형태로 쓴다) ②PendingMigrationError: navigator is now a global in nodejs → 무해(원격 exthost 에서 늘 3건 뜨는데 로컬 창엔 안 뜬다).
⚠노트북 화면 캡처는 화면이 꺼져 있으면 새까맣게 나온다(입력 이벤트로 깨워도 안 켜짐 — 덮개 닫힘). 창만 PrintWindow(PW_RENDERFULLCONTENT=2) 로 뜨면 화면이 꺼져 있어도 내용이 나온다. 실물 = C:\dev\_work\vscode-lap\verify3.ps1(schtasks /IT + 숨김 .vbs).
[코디] 🔑미니PC 는 윈도우 업데이트로 저 혼자 재부팅하지 않는다 — 대신 텔레그램으로 알린다(26.9.15 페페 지시, 04:14 자동재부팅으로 LIVE STT 가 죽은 뒤). 정책 3겹 = HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU 의 AUOptions=2(다운로드·설치 전 알림만) · NoAutoRebootWithLoggedOnUsers=1(미니PC 는 자동로그인이라 «항상 로그온» = 사실상 영구 차단) · AlwaysAutoRebootAtScheduledTime=0 + 오케스트레이터 Schedule Wake To Work 비활성화. 적용·되돌리기 = C:\dev\tools\winupdate-guard\apply_policy.ps1(머리에 undo 명령, el.py 로 SYSTEM 실행 — 비관리자로는 정책 키를 못 쓴다).
알림 = 예약작업 \Cody\winupdate-guard → C:\dev\tools\winupdate-guard\wuguard.py. 트리거 3개 = WindowsUpdateClient 19·43·44 · User32 1074(누가 재부팅을 걸었다) · 매일 09:30(대기 업데이트 COM 검색). 보내는 경우는 재부팅이 걸렸다 · 재부팅 대기 · 설치 안 된 업데이트 뿐이고 그 밖엔 조용하다(같은 상태 24시간 억제, 단 재부팅 요청은 억제하지 않는다 — 그게 이 도구의 존재 이유).
⚠판정 명령은 Git Bash 에서 MSYS_NO_PATHCONV=1 없이 못 쓴다 — shutdown /r /t 900 의 /r·/t 를 MSYS 가 경로로 바꿔 사용법만 출력하고 아무 일도 안 일어난다(26.9.15 실측, 겉보기엔 「걸렸다」로 착각하기 쉽다). 트리거 시험 = MSYS_NO_PATHCONV=1 shutdown /r /t 900 → 즉시 shutdown /a(두 번째 /a 가 「진행 중인 종료 없음 1116」이면 확실히 취소된 것) → 1074 발생 1초 뒤 작업 기동을 _run.log 로 확인.
⚠맞바꾼 것 = 보안 패치가 「페페가 누를 때까지」 안 깔린다. 알림이 오면 「설정 > Windows 업데이트」에서 사람이 진행한다. 정책이 실제로 먹었는지의 육안 신호 = 그 화면의 「조직에서 일부 설정을 관리합니다」.
⚠pythonw 로 도는 예약작업 스크립트는 sys.stdout 이 None 이다 — 진입부 sys.stdout.reconfigure(...) 를 조건 없이 쓰면 즉사하고, 자식으로 부르는 notify.py 도 pythonw.exe 로 넘기면 같이 죽는다(sys.executable.replace('pythonw.exe','python.exe')). 로그는 stdout 대신 파일에 쓴다.
⚠vbs → cmd /c "python" "script" >> log 는 인용이 깨져 조용히 아무것도 안 한다(로그 파일조차 안 생긴다 · 예약작업은 LastTaskResult 0 으로 성공처럼 보인다). 창 없이 파이썬만 돌릴 거면 예약작업 액션에 pythonw.exe 를 직접 적는 게 껍데기 하나 줄이고 확실하다.
[코디] 🔑새 클라이언트 PC → 미니PC VS Code 원격 개통 체크리스트(26.9.11 노트북에서 확립) — ①그 PC 공개키를 미니PC C:\ProgramData\ssh\administrators_authorized_keys 에(delix 가 관리자라 ~/.ssh/authorized_keys 는 무시된다 · el.py 로 쓰면 ACL 유지) → 그 PC 에서 ssh -o BatchMode=yes poin-mini hostname 통과 ②~/.ssh/config poin-mini = 사무실PC 값(rules/remote.md 함정18) ③Remote-SSH 0.126.0 3종 세트(함정19) ④VS Code 신뢰 기능 끄기(아래 🔴) ⑤Code.exe --folder-uri vscode-remote://ssh-remote+poin-mini/c%3A/dev 바로가기.
🔴④ 신뢰 사전등록만으론 부족했다 → 신뢰 기능을 끈다(26.9.11 22:2x 페페 실측 — 사전등록 뒤 원격 로그상 Claude 는 매번 활성화됐는데 화면엔 「이 폴더를 신뢰하냐」가 계속 떴다, 원인 미확정). ⛒클라이언트 사용자 설정 "security.workspace.trust.enabled": false 를 VS Code 를 끈 상태에서 넣는다(켜진 채 바꾸면 「재시작 필요」 창이 또 뜬다). ✅이 처방으로 사라진 것 페페 육안 확인(26.9.11). 참고 = 신뢰 목록 저장처는 클라이언트 %APPDATA%\Code\User\globalStorage\state.vscdb → ItemTable 키 content.trust.model.key, 값 {"uriTrustInfo":[{"uri":{"$mid":1,"path":"/c:/dev","scheme":"vscode-remote","authority":"ssh-remote+poin-mini"},"trusted":true}]} · Remote-SSH 는 신뢰를 강제하지 않는다(확장 코드 isTrusted 0건) · Claude 확장엔 폴더 신뢰 대화상자가 없다(문구 0건).
⚠원격 로그로 신뢰 판정은 반쪽이다 — Claude 확장은 untrustedWorkspaces.supported:false 라 미니PC ~/.vscode-server/data/logs/*/exthostN/remoteexthost.log 에 _doActivateExtension Anthropic.claude-code 가 찍히면 VS Code 가 신뢰로 본 것이지만, 그래도 화면 질문은 떴다 → 질문 유무는 페페 육안이 정본(노트북이 잠겨 있으면 화면 캡처도 PIN 화면뿐).
⚠extensions.autoUpdate 는 VS Code 1.137 부터 "on"/"off" — false 를 넣으면 설정 마이그레이션이 "off" 로 바꾼다(사무실PC 의 "off" 가 정답).
[코디] 🔑윈도우 내장 sshd 를 최신 Win32-OpenSSH 로 올릴 땐 서비스 binPath 만 바꾼다(26.9.11 노트북 9.5p2 → 10.0p2). 내장(FoD) 서버 제거 + MSI 는 ①MSI 가 같은 sshd 서비스 이름을 만들어 충돌하고 ②재부팅 대기(RebootPending) 중이면 DISM 제거가 반쯤 걸려 다음 재부팅 때 서비스가 지워질 수 있다(원격 PC 면 잠김). ⛒GitHub zip(서명 확인) → C:\Program Files\OpenSSH → sshd.exe -t -f C:\ProgramData\ssh\sshd_config 통과 → sc config sshd binPath= → 15초 안에 22 리슨이 없으면 자동 되돌림. 설정·호스트키·administrators_authorized_keys 는 C:\ProgramData\ssh 공용이라 그대로 산다. SSH 세션 안에서 돌리면 서비스 중지로 끊기니 SYSTEM 1회 예약작업으로 던지고 미니PC에서 배너를 폴링(3초 만에 10.0). 판정 = ssh -v 의 kex: algorithm: mlkem768x25519-sha256(Git Bash ssh 10.x 의 post-quantum 경고가 사라진다). 스크립트 = 노트북 C:\ProgramData\cody-sshup\{sshup,sshdown}.ps1. ⚠윈도우 업데이트가 내장 OpenSSH 를 갱신하면 binPath 가 9.5 로 돌아갈 수 있다(접속은 유지) → 재실행.
⚠노트북(배터리)에서 schtasks/Register-ScheduledTask 로 Session 1 GUI 를 띄울 땐 -AllowStartIfOnBatteries + -ExecutionTimeLimit 0(기본 72시간 제한이 띄운 VS Code 를 죽인다). ⚠Session 1 에서 숨김 taskkill /IM Code.exe(정상 종료)는 20초 안에 VS Code 를 못 닫았다 → 강제 종료로 넘어갔다.
[코디] 🔑미니PC 「팬이 크게 돈다」 판정 순서(26.9.11) — ①CPU 20초 창 샘플(psutil cpu_times 차분, 순간값 금지) ②\GPU Engine(*)\Utilization Percentage ③powercfg /getactivescheme. ⚠온도는 \Thermal Zone Information 이 293K 고정 더미(8745HS ACPI TZ)라 못 쓴다 → 실온도는 LibreHardwareMonitor. 26.9.11 실측 = CPU 평균 1.8%·최대 4.8%·GPU 0 → 소프트웨어 부하 아님. 정리(ChatGPT/Codex 앱 종료[페페 직접 지시] + memclean.py --clean 고아 MCP 4·잔재 셸 19)로 램 52.5→47.5%. 남은 용의자 = 전원계획 고성능(부스트 공격적) — 균형+절전 0 전환은 페페 결정 대기.
🔴SSH(Session 0)로 프로그램을 제거할 때의 함정 4건(2026-09-02 사무실PC poinimos01 실측, 전부 조용히 실패해서 「했다」고 오보하기 쉽다). 1. Start-Process는 SSH 세션에서 무음 실패한다 — -PassThru로 받은 객체가 비어 WaitForExit도 ExitCode도 안 잡히고, try/catch에도 안 걸린 채 아무 일도 안 일어난다(메모리 cody-elevated-runner 의 「ExitCode null」과 같은 뿌리). ⇒ cmd /c 직접 호출로 실행하고, 따옴표가 꼬이면 .bat 파일을 만들어 cmd /c <bat> 로 돌린다(인라인 따옴표 지옥 회피). 2. ⛔msiexec 의 rc=0 은 성공의 증거가 아니다. 다른 MSI 작업이 물려 있으면 Failed to grab execution mutex. System error 258 로 아무것도 안 하고 0을 반환한다. ⇒ 판정은 레지스트리 ...\Uninstall\* 에서 DisplayName 이 실제로 사라졌는지로만 한다. Windows Installer는 단일 인스턴스라 완전 직렬화 필수. 3. ⛔InstallShield 계열 언인스톨러(C:\Windows\Installer\{GUID}\uninstall.exe)는 SSH에서 무한정지한다 — /silent 를 안 먹고 GUI 대화상자를 띄우는데 Session 0에는 화면이 없다. 증상 = 프로세스가 살아있는데 CPU 0초(9분 방치 실측). 배치 안에 두면 뒤 항목이 전부 실행되지 않고, 게다가 MSI 뮤텍스를 잡고 있어 앞 항목까지 2번 증상으로 죽인다. ⇒ MSI ProductCode 직접 제거(msiexec /x {GUID} /qn)로 우회하고, 그래도 GUI면 페페에게 제어판 클릭으로 넘긴다. 4. Visual Studio 제거 3종 함정 — ⓐvs_installer.exe/setup.exe 는 비동기다(작업을 띄우고 즉시 rc=0 반환) → 완료 판정은 설치폴더 크기 폴링으로 한다. ⓑ--wait 는 존재하지 않는 플래그(rc=87 ERROR_INVALID_PARAMETER). --nocache 도 uninstall 과 같이 쓰면 87. 쓸 수 있는 건 --quiet --norestart 뿐. ⓒ VS 프로세스가 하나도 없는데도 Pre-check verification failed: VSProcessesRunning(exit 8006)으로 거부한다(설치관리자가 자기 헬퍼를 센다) → --force 를 붙이면 통과하고, 그때부터는 동기 실행이라 블록된다. 로그는 %TEMP%\dd_installer*.log.
곁가지 = UWP SDK·ASP.NET Web Tools 같은 VS 구성요소 MSI는 단독 제거가 안 된다(VS 설치관리자 소유). VS 본체를 먼저 지우고 남은 것만 msiexec /x 로 턴다. 순서를 뒤집으면 전부 헛돈다.
Autodesk ODIS 번들 제거 로그의 Uninstall successful for package <VC++ 재배포판 / .NET Framework 4.8 / DirectX> 는 자기 번들에서의 참조 해제 기록이지 시스템 제거가 아니다(다른 제품이 참조 중이면 건너뛴다). 실측 확인 = 재배포판 전 세대·NDP\v4\Full Release 533325·핵심 런타임 DLL 전부 잔존. 놀라서 되돌리지 말 것.
🔴Windows C: 용량 부족의 1순위 범인 = C:\Windows\Installer 고아 MSI/MSP (2026-09-02 사무실PC poinimos01 실측 55.9GB, 정상은 1~5GB). CAD·Office 재설치를 반복한 업무기는 여기가 터진다. 탐색기 폴더 크기로는 안 보인다(숨김+시스템). 판정·처방 = WindowsInstaller.Installer COM 한 경로: ProductsEx("","s-1-1-0",7) → 각 제품 InstallProperty("LocalPackage") + PatchesEx(...) → PatchProperty("LocalPackage") 로 참조되는 파일 집합을 만들고, 그 집합에 없는 .msi/.msp 가 고아다(실측 1410개 51.2GB 중 690개 42.8GB가 고아). ⚠바로 지우지 말고 다른 드라이브로 Move-Item — 제거/복구/업데이트가 며칠 정상이면 그때 삭제(가역). Win32_Product 로 열거하면 설치된 제품이 재구성(reconfigure)돼서 위험하니 쓰지 말 것. $PatchCache$ (실측 4.1GB)도 같이 옮겨도 된다(Office 복구용 소스, 재생성 가능).
🔴🔴26.9.10 정정 — 위 판정식은 틀렸다(필터 1 = 「적용 중」만 참조로 셌다). 대체된(State=2) 옛 패치 .msp 685개가 「고아」로 분류돼 삭제됐다. 같은 날 $PatchCache$ 도 비웠고 C:\MSOCache(오피스 원본 952MB)는 D:\_cody_MSOCache 로 옮겼다. 그 결과 26.9.10 엑셀 패치(KB5002914)를 제거하려 하자 MSI가 없는 패치 1,409건을 하나씩 원본에서 찾았다 — 미디어 원본 단계에서 건당 최대 27초, 평균 10초라 제품 6개 합계 3시간 이상 걸릴 판이었다(에러 없이 「느리기만」 하다). ⛒고아 판정은 PatchesEx(..., 7, 15)(모든 상태)로 한다. MSOCache· $PatchCache$ 는 옮기지도 비우지도 마라 — 패치를 빼거나 복구할 때 쓰는 원본이다. 이미 지운 뒤라면 HKU\S-1-5-18\Software\Policies\Microsoft\Windows\Installer\SearchOrder=n(설치 계정 SYSTEM의 사용자 정책) 을 임시로 넣으면 건당 0.15초로 줄어든다(실측 581건 1분). 작업 뒤 값을 삭제한다.
같이 나오는 조연 = hiberfil.sys(12.75GB. HiberbootEnabled=0(빠른시작 OFF) + 무중단 가동일수가 길면 = 최대절전 실사용 0 → powercfg /h off, 되돌리기는 /h on) · Chrome OptGuideOnDeviceModel(3.98GB, 온디바이스 AI 모델·자동 재다운로드) · Claude Desktop Packages\Claude_*(21.5GB, vm_bundles 가 대부분) · Service Worker\CacheStorage(크롬 프로필당 0.9GB).
⛔카톡 AppData\Local\Kakao\KakaoTalk\users\<해시> 는 절대 건드리지 않는다(실측 13.9GB = 대화 DB·미디어 원본, 지우면 대화가 날아간다). 지워도 되는 건 Kakao\AdFit\EBWebView\...\Cache(광고 웹뷰, 0.3GB)뿐.
마무리 = 저장 공간 센스(Storage Sense) 를 켜 재발을 막는다. HKCU ...\StorageSense\Parameters\StoragePolicy — 01=1(ON) 04=1(앱 미사용 임시파일) 08=1(휴지통) 32=30(휴지통 일수) 02=0(다운로드 폴더 정리 OFF — 페페 파일이라 반드시 0) 2048=7(주간). SSH 세션이 곧 poinpc 라 HKCU 가 정확히 대상 사용자다.
실측 결과 = C: 여유 155.8 → 277.3GB(33.6% → 59.7%, +121.5GB). 내역 = 고아 Installer 46.9 · Visual Studio 스택 22(2017+2026+SDK+빌드툴, 아래 함정 4번) · hiberfil 12.75 · Claude Desktop uv 캐시 12.1 · 임시/캐시/휴지통 8.0 · 재다운로드 가능 설치본 12.9(NVIDIA 드라이버 3.4·Autodesk Downloads 2.0·SQL 업데이트캐시 1.9·Downloaded Installations 1.8·C:\Autodesk 1.5 등) · ZWCAD 1.4 · DWG TrueView 2022 1.1. DISM /StartComponentCleanup 은 0.45GB밖에 안 준다(WinSxS 11.9GB는 이미 정상) — 여기에 시간 쓰지 말 것.
미사용 프로그램 판정 = C:\Windows\Prefetch\*.pf 의 LastWriteTime(= 그 exe 마지막 실행). 설치 목록·폴더 날짜보다 정확하고 공짜다. 실측 = DEVENV(VS) 3개월 · ZWCAD 기록 0(설치 후 한 번도 안 씀) · STEAM 1년 · ACAD/EXCEL/CODE 당일. ⚠정리 스크립트에서 Prefetch 를 지우면 이 증거가 사라진다 — 조사 먼저, 삭제 나중.
⛔C:\Program Files (x86)\InstallShield Installation Information 은 통째로 지우면 안 된다(실측 5.32GB). 각 {GUID} 폴더가 그 제품의 제거 데이터다 — 실측 소유자 = 2.99GB iX CAD 2023(운영 중) · 1.07GB SketchUp 2026(운영 중). 지우면 정식 제거가 막힌다. 소유자 판정 = 레지스트리 Uninstall\* 의 UninstallString/ModifyPath 에 그 GUID 가 있는지.
Office 2016 은 C:\Program Files\Microsoft Office\Office16\EXCEL.EXE(MSI 설치, 64비트). Click-to-Run 의 ...\root\Office16\ 경로로 확인하면 없다고 나와 오진한다 — 검증 경로를 틀리게 잡고 「Office 가 깨졌다」고 보고하지 말 것.
미니PC에서 사무실 프린터·팩스 = 서브넷 라우트 위 RAW 9100 직결(2026-08-27 설치). 신도 SINDOH D450/CM Series PCL·FAX 2개, 포트 IP_192_168_0_201(192.168.0.201:9100 RAW·SNMP off). 사무실PC 공유 프린터가 아니라 장비 IP 직결이라 서브넷 라우터 poinimos01이 켜져 있어야 인쇄된다(꺼지면 인쇄 실패 — 페페 고지 완료). 드라이버는 신도 사이트에서 새로 받지 말고 poinimos01 DriverStore\FileRepository 2폴더(koaxbja_=PCL·koaxbsa_=FAX)를 zip→scp→pnputil /add-driver <inf> /install 로 이식하면 모델·버전이 완전히 일치한다. 프린터 등록은 el.py(SYSTEM)로 Add-PrinterDriver→Add-PrinterPort→Add-Printer.
진단 1줄 = 소스 바인드 비교(2026-08-10 확정). socket.bind(('192.168.45.48',0))(물리 NIC) → 1.1.1.1:443 OPEN, bind(('10.73.241.2',0))(터널) → timeout. 물리 인터넷은 멀쩡하고 죽은 터널이 기본 경로만 먹고 있다는 증거. Find-NetRoute는 후보만 보여줘 판단이 안 서고, 단발 TCP 테스트는 가끔 OPEN이 튀어 오판을 부른다(반복 4회로 확인할 것).
WG poin은 full-tunnel(0.0.0.0/1+128.0.0.0/1)이라 터널이 죽으면 미니PC 인터넷 전체가 죽는다(2026-08-10 실측). 인터페이스는 Up·서비스는 Running인데 Get-NetAdapterStatistics -Name poin = rx/tx 0이면 핸드셰이크 0 = 블랙홀. 이때 Tailscale(100.x)만 살아남아 코디 세션·DNS는 정상으로 보이므로 "사무실 LAN만 안 된다"고 오진하지 말 것 — 판정은 1.1.1.1:443 같은 공인망 TCP 1발로 한다. 텔레그램 broker 500도 같은 증상(발송 경로 = 노트20 카톡 poin-agent/phone.py로 우회). 복구 = C:\dev\tools\restart_wg_poin.ps1 관리자(코디 Bash는 비관리자라 Restart-Service 거부). 계기 = 윈도우 업데이트 재부팅 후 DDNS 엔드포인트 해석 실패 추정.
노트북↔미니PC SMB는 통과인증이 안 된다(2026-08-07 실측). 노트북 delix = Microsoft 계정, 미니PC delix = 로컬 계정 → 같은 이름이어도 자격증명이 다르다. 노트북엔 저장 자격증명 0건이었다(cmdkey /list 비어있음). 해법 = 노트북에 cmdkey /add:100.108.234.45 /user:POIN-MINI\delix 1회 저장. 미니PC dev 공유는 이미 존재(공유 Everyone Full · NTFS 인증사용자 Modify).
SSH(키인증) 세션에서는 원격 SMB 접근이 원천 불가. OpenSSH 키 로그온 토큰엔 자격증명이 없어(S4U) Test-Path \\peer\share가 항상 PermissionDenied다. 방화벽·공유 문제로 오진하지 말 것. 명시 자격증명(net use /user:)을 주거나 대화형 세션에서 돌려야 한다. 같은 이유로 DPAPI가 안 풀려 cmdkey 영속 저장도 신뢰할 수 없다.
schtasks /it로 만든 작업이 SSH에서 /run 해도 세션1에서 안 뜬다(2026-08-07, 노트북 세션3에 explorer 살아있는데도 last result 0인 채 미실행). 대화형 실행이 꼭 필요하면 바탕화면 스크립트를 깔아두고 페페가 1회 클릭하는 쪽이 확실하다.
탐색기 즐겨찾기 = Quick Access 핀. 등록은 Shell.Application.Namespace(<경로>).Self.InvokeVerb('pintohome'), 확인은 Namespace('shell:::{679f85cb-0220-4080-b29b-5540cc05aab6}') 열거. 비대화형 세션에서 핀은 안 먹는다(열거는 됨).
페페용 대화형 .ps1은 UTF-8 BOM으로 저장한다. Windows PowerShell 5.1은 BOM 없는 UTF-8을 cp949로 읽어 한글 메시지가 깨진다. Write 도구로 쓴 뒤 encoding='utf-8-sig'로 다시 저장할 것.
미니PC 인터넷은 유선 고정.(2026-08-01 페페 전환) 서브넷 라우터·Funnel·Remote-SSH가 전부 미니PC 네트워크에 얹혀 있어 Wi-Fi 전환마다 터널이 끊겼다. 무선으로 되돌리지 말 것. 네트워크를 갈아탄 뒤엔 포워딩(Tailscale·poin Enabled)·PrimaryRoutes·Funnel 3개를 재확인한다(Tailscale 재설치로 인터페이스가 새로 생기면 포워딩이 날아간다).
경로 선택 기본값 = Tailscale. PC·폰 대상이면 Tailscale로 먼저 푼다. WireGuard는 Tailscale을 못 올리는 기기(NAS 같은 임베디드 어플라이언스)나 직결 속도가 실제로 필요할 때만. 이유 = 라우터 admin 자격이 상시 병목이고, Tailscale은 어디서든 붙고 kill-switch 사고가 없다. (2026-07-31 페페 결정 "A 먼저, B는 나중")
LAN 통째로 필요하면 노드를 늘리지 말고 서브넷 라우터를 쓴다. 사무실 LAN에 Tailscale 못 까는 기기가 여럿이면 미니PC 하나를 서브넷 라우터로 두는 게 정답(기기별 설치·피어등록 0).
Windows 서브넷 라우터는 IP 포워딩까지 켜야 끝난다. 광고(tailscale set --advertise-routes) + admin 승인 + 인터페이스 Forwarding Enabled 3개가 전부 충족돼야 통한다. 앞의 둘만 보고 "개통"이라 보고하지 말 것 — 셋 다 정상으로 보이는데 패킷이 죽는 상태가 실제로 있었다.
라우트 변경은 tailscale set, tailscale up 금지. up은 지정 안 한 플래그를 기본값으로 되돌려 Funnel·exit node 설정을 날린다.
개통 판정은 실제 파일 접근까지. PrimaryRoutes 표시·포트 열림은 근거가 안 된다. 탐색기에서 공유 폴더 목록이 보이는 것까지가 "됨"이다(rules/remote.md "포트 열림 ≠ 접근 가능"과 동일 원칙).
폰(adb shell)은 네트워크 검증 도구가 아니다. VpnService 밖이라 tailnet 자체가 안 잡힌다. 검증은 실제 PC에서.
미니PC 의존을 페페에게 명시한다. 서브넷 라우터 구성에서 미니PC가 꺼지면 노트북·폰의 사무실 LAN 접근이 같이 끊긴다. 이 트레이드오프는 채택 시 1회 고지하고 handoff에 남긴다.
🔴🔑「커서가 부자연스럽게 움직인다」 = 마우스 가속(향상된 포인터 정밀도)이다. 훅·CPU·드라이버부터 파지 마라(26.8.28 실측, 코디 오진 경로 포함). 증상 = 「빠르게 움직이려면 엄청 느려진다 · 부자연스럽다」. 코디는 입력 처리 병목으로 읽고 저수준 훅부터 팠다 — WH_MOUSE_LL 훅 3개(tools/vscode-tray/vstray.pyw 파이썬 훅 + PowerToys FindMyMouse·MouseHighlighter)를 찾아 다 내렸는데 「조금 원활해졌다」에 그쳤다. 진짜 원인 = HKCU\Control Panel\Mouse 의 MouseSpeed=1(가속 ON) + MouseSensitivity=6(기본 10). 가속이 켜지면 같은 물리 이동량에도 속도에 따라 커서 이동량이 달라져 손이 예측을 못 한다 = 「부자연스럽다」의 정체. 처방 = SystemParametersInfoW(SPI_SETMOUSE, [0,0,0]) + SPI_SETMOUSESPEED=10, 플래그 SPIF_UPDATEINIFILE|SPIF_SENDCHANGE 로 즉시 반영(재부팅 불필요). 🔑판정 순서 = ①Control Panel\Mouse 의 MouseSpeed·MouseSensitivity ②주사율 ③그 다음에야 훅·DPC. DPC 0.17%·인터럽트 0.52% 면 드라이버는 무죄다(측정 = Get-Counter '\Processor(_Total)\% DPC Time'). 부수 = 훅 정리·전원계획 고성능은 그대로 뒀다(파이썬 훅 CPU 3,757초 제거는 순이득). 미니PC 모니터 = LF27T35·S27C31x, 75Hz 지원인데 59Hz 로 돌고 있었다.
WG poin 이 26.8.27 「내렸다」 기록 뒤에 다시 켜져 있는 이유 = 그날 저녁 NAS 파일 작업용 일회성이었다(상시 유지 결정이 아니다). 근거 = projects/pfs/session-2026-08-27-rdstunnel-orderpaper-vendor-query.md — 「NAS 접근은 WG 터널 poin 필요(미니PC LAN 은 192.168.45.x 라 NAS 와 다른 대역)」「SSH(Session 0)에선 UNC/SMB 가 무조건 막히므로 사무실PC 원격으로 NAS 를 읽는 길이 없다 → 미니PC 에서 WG 를 켜고 로컬로 읽었다」. 🔑그 목적은 지금 Tailscale 로 이미 충족된다(26.8.28 실측: NAS 192.168.0.101 → Tailscale 경유 · SMB 445 열림 · 13ms). poinimos01 이 서브넷 라우터가 된 뒤로 WG 없이도 사무실 LAN 에 닿기 때문이다. ⚠켜둔 대가 = 192.168.0.0/24 라우트가 WG·Tailscale 동일 metric 5 로 2줄 → 목적지마다 경로가 갈린다. 실측 = 192.168.0.41 imos MSSQL WG 경유 425ms(Tailscale 13ms 의 32배) · QC1 192.168.0.25 는 21,057ms 타임아웃 실패. → 작업이 끝나면 WG 는 도로 내리는 게 규칙이다. 안 내리면 다음 사람이 「LAN 이 반반 갈린다」로 헤맨다.

🆕 신규 — gpubox 동시사용 충돌 (26.9.1)

🔴tools/gpubox/gpubox.py 에 락·소유권이 없다 — 두 세션이 같이 쓰면 한쪽 off() 가 남이 작업 중인 집PC를 끈다. wake/run/off 개별 호출 방식이 특히 취약(job() 한 방이 그나마 안전).
✅해결됨(같은 날, dev-ed 구현·selftest 통과·코디 실측 확인) — claim / release / who 신설. 클레임 파일 = tools/gpubox/gpu.claim.json · TTL 2h(넘으면 죽은 세션 잔재로 보고 무시) · 클레임 없으면 허용(기본 개방) · 자기 것은 재진입 OK · 남의 것은 release 불가 · 거부는 off 에서만(강제로 끄려면 off --force).
🔑그래도 off 는 아예 안 부르는 게 낫다(ghostdex 세션 실측 조언) — wake/run/push/fetch 만 쓴다. 락은 보험이지 보장이 아니다.
🔑배치는 조건마다 결과를 집PC 디스크에 찍는다 — 남이 꺼도 완료분이 남아 이어 돌린다. 락보다 이게 확실한 보험이다.
세션 간 조율 함정 = peer 주소(uds:\.\pipe\...)는 상대가 재시작하면 stale 이라 회신이 ECONNREFUSED 로 죽는다. ListAgents 로 현재 주소를 다시 잡는다. 이름이 목록에 없으면 그 세션은 이미 끝난 것.
실측 = ghostdex 리포의 gpubox 참조는 README 1건뿐, 실행 코드엔 없다(GPU 작업은 「Ghostdex 목판화 화풍 로컬화」 Remote Control 세션이 새로 붙이는 중).

🆕 신규 — 미니PC→집PC 백업 tar-over-ssh (26.9.2)

[코디] 도구 = C:\dev\tools\homebackup.py. 대상 = 집PC D:\backup\poin-mini\current\(WD Blue 2TB, 가동 7,784h·읽기에러 0). E: 는 쓰지 마라 — ST2000DM001 은 실패율 악명 높은 모델이고 실측 읽기에러 48건이 이미 쌓였다.
방식 = 양쪽 매니페스트(경로·크기·mtime) 대조 → 달라진 것만 tar 스트림 over ssh. rsync 는 집PC 에 없고 SMB 비번은 .secrets/.env 에 없다 → 이미 있는 SSH 키 하나로 되는 길이 이것뿐. 대조는 26만 파일에 10~70초. 실측 전송 44MB/s(대용량)·5MB/s(4.7만 소파일).
🔴--format=posix 없으면 한글 파일명이 통째로 사라진다. GNU tar 기본(gnu) 포맷은 이름을 로컬바이트로 싣고, 받는 쪽 bsdtar 가 Invalid empty pathname 으로 건너뛴다 — 전송은 계속돼서 모르고 지나간다(실측 122/125). pax 로 125/125.
🔴파이썬 subprocess 에서 tar 는 GNU tar 가 아니다. 윈도 PATH 의 C:\Windows\system32\tar.exe(bsdtar)가 잡혀 --format=posix·--ignore-failed-read 를 모른다 → C:\Program Files\Git\usr\bin\tar.exe 절대경로로 고정. bash 스크립트는 /usr/bin/tar 라 안 겪는다.
🔴tar 의 stderr 를 subprocess.PIPE 로 두면 교착. 잠긴 크롬프로필 경고만 수백 줄이라 64KB 버퍼가 차는 순간 tar 가 멈추고 ssh 도 같이 멎는다(10분 무응답 실측) → stderr 는 임시파일로 받는다.
함정 = 원격 PowerShell 은 $ProgressPreference='SilentlyContinue' + 끝에 exit 0 이 없으면 진행률 CLIXML 이 stderr 로 나가며 종료코드를 오염시킨다. 그리고 [Console]::Out.WriteLine("{0}t{1}" -f $a,$b)` 는 쉼표가 WriteLine 의 인자로 먹혀 포맷이 터진다 → 변수로 풀어 쓴다.
잔여 불일치는 정상이다 — 돌아가는 CDP 크롬 프로필·상주 로그·.git 오브젝트·SQLite WAL 은 뜨거운 상태라 매번 몇십~몇백 개 어긋난다. --dry 로 위치만 보고 넘긴다.
한계(설계) = 증분은 삭제를 전파하지 않는다. 사본에만 남은 건 --delete 로 따로 치운다. 백업이니 더 남는 쪽이 안전한 기본값.
🔴로컬 스캔은 반드시 \\?\ 접두사로. 미니PC 는 LongPathsEnabled=0 이라 260자 넘는 경로를 os.walk 가 에러 없이 건너뛴다(실측 Unity 산출물 282자). 백업에 안 올라갈 뿐 아니라 --delete 가 사본의 멀쩡한 파일을 「원본에 없다」며 지운다 — 백업 도구에선 이게 제일 위험한 버그다.
함정 = 원격 명령은 집PC 의 cmd.exe 를 거쳐서 한계가 32KB 가 아니라 8KB. -EncodedCommand 는 base64(UTF-16LE)라 원문의 ~2.7배 → 원문 2,000자로 잘라 보낸다(314건 한 방·6,000자 둘 다 WinError 206 으로 터졌다).
집PC 는 평소 꺼져 있다 → ensure_up() 이 포트 확인 후 gpubox.py wake(33초). 끄는 건 스크립트가 안 한다 — gpubox claim/release/off 로 따로 판단.

🆕 신규 — 상주 서비스 로그 30일 보관 (26.9.2)

[페페 지시] rc.log 2.53GB · broker.log 512MB → 30일치만 남긴다.
🔴>> 리다이렉트로 쌓는 로그는 밖에서 잘라도 소용없다. 프로세스가 핸들과 오프셋을 쥐고 있어 다음 쓰기가 옛 오프셋에 떨어지고 그 앞이 0으로 메워져 원래 크기로 되돌아온다. 자르는 쪽이 아니라 쓰는 쪽을 바꿔야 한다.
처방 = C:\dev\tools\logrot.py — stdin 을 TimedRotatingFileHandler(midnight, backupCount=30) 로 받아쓴다. ... 2>&1 | python -X utf8 logrot.py <로그> 30 로 갈아끼우면 그 뒤로 재시작이 영영 필요 없다. --selftest 있음.
start_remote_control_silent.vbs 적용. python 은 절대경로로 고정(bare python 은 PATH 1순위 venv 에 묶인다).
파이썬 서비스는 그냥 핸들러 교체 — broker.py 의 logging.FileHandler → logging.handlers.TimedRotatingFileHandler(when="midnight", backupCount=30). ⚠import logging 만으론 logging.handlers 가 없다, 따로 import.
적용은 재시작 필요 → 프로세스를 죽이면 양쪽 워치독이 1분 안에 되살린다(rc = watchdog.ps1 1분 태스크, broker = CodyPermissionBroker 태스크 + 포트 7777 감시). 옛 대용량 로그는 그 틈에 attic 으로 옮긴다.
broker 는 pythonw 2개(venv + Python39)가 같은 시각에 뜨는 게 정상이다. 중복 아님, 워치독이 보는 건 포트 7777.

🆕 신규 — 새 PC SSH 개통은 USB 원클릭 설치킷으로 (26.9.3)

도구 = C:\dev\tools\ssh-setup-usb\(원본) → USB 배포본 E:\cody-ssh\. 첫 대상 = poinimos02.
구성 = INSTALL_SSH.bat(자가 UAC 승격) + setup_ssh.ps1 + OpenSSH-Win64.zip(오프라인 대체) + 사용법.txt + test_keyappend.ps1(자체검사).
하는 일 = OpenSSH Server 설치 → sshd 자동시작 → 방화벽 22 를 192.168.0.0/24+100.64.0.0/10 으로만 → 공개키 설치 → 결과를 USB 에 result_<호스트>.txt.
🔴키는 두 곳에 다 넣는다 — 실행 계정이 관리자면 sshd 가 ~/.ssh/authorized_keys 를 조용히 무시하고 %ProgramData%\ssh\administrators_authorized_keys 만 읽는다(rules/remote.md 함정15). 어느 쪽인지 모르니 둘 다 + icacls /inheritance:r 로 Administrators·SYSTEM 만.
🔴기존 파일이 개행으로 안 끝나면 키 두 개가 붙어 둘 다 죽는다 → append 전에 빈 줄 하나. 재실행해도 중복 안 넣는다.
🔴PowerShell 은 네이티브 명령 인자 안의 (식) 을 전개하지 않는다 — netsh ... remoteip=($a -join ',') 는 리터럴로 나간다. 변수에 먼저 담아 remoteip=$remote.
신규 PC 에 Tailscale 은 안 깐다 — poinimos01 이 192.168.0.0/24 를 광고하므로 미니PC 는 LAN IP 로 바로 붙는다.
🔴26.9.3 실패에서 고친 것 = 방화벽 규칙 순서. 옛 판은 기본 OpenSSH-Server-In-TCP 규칙을 먼저 끄고 내 스코프 규칙을 만들었다. 생성이 실패하면 22 가 오히려 더 닫힌다. ⛒내 규칙 생성 → 존재 확인 → 그 뒤에만 기본 규칙 끄기(실패하면 기본 규칙을 켠다). 같은 형태의 사고를 ipwatch(추가→검증→삭제)에서 이미 배웠는데 여기서 되풀이했다.
🔴Start-Service -EA SilentlyContinue 는 개통 스크립트에서 쓰지 마라 — 서비스가 안 떠도 리포트가 초록으로 나간다. 판정은 listening22 만으로 부족하고 127.0.0.1:22 실제 TcpClient 접속까지 봐야 한다(포트 열림 ≠ 접속 가능, remote.md §3).
🔴「LAN 에서도 닫힘」이 라우팅 무죄의 증거다 — 미니PC 뿐 아니라 같은 LAN 의 poinimos01 에서도 닫혀 있으면 서브넷 라우트·Tailscale 을 파는 건 헛수고다. 같은 호스트의 다른 포트(445)가 열려 있는지를 대조군으로 쓴다.

🆕 신규 — 원격 PC 의 AutoCAD 를 조종하려면 Session 1 로 넘겨야 한다 (26.9.3)

도구 = C:\dev\tools\acadctl\ (acad_idle_restart.ps1 = 유휴 감지 후 저장·재시작·도면복원 무인 실행).

🔴SSH 는 Session 0 다 → GetActiveObject('AutoCAD.Application') 이 무조건 실패한다. 캐드가 멀쩡히 떠 있어도 그렇다(COM ROT 가 세션별). GetLastInputInfo(사용자 유휴시간)도 세션별 — Session 0 에서 부르면 사용자 입력과 무관한 값이 나온다. 둘 다 schtasks /it 로 Session 1 에 넘겨서 돌린다.
🔴schtasks 로 되는 조합은 하나뿐이다(전부 실측): · /tr 은 공백 없는 단일 토큰 — wscript.exe C:\...\run.vbs 처럼 공백이 있으면 ssh→cmd 가 쪼개 「잘못된 인수/옵션」. .vbs 경로만 주면 연결프로그램이 wscript 다. · /ru 를 주지 마라 — SSH 세션에선 계정 이름이 안 풀린다. 생략 = 현재 사용자. · 명령 전체를 작은따옴표로 감싸라 — 안 감싸면 C:\ProgramData\... 의 백슬래시가 통째로 사라져 C:ProgramDataCodyAcadrun.vbs 로 등록된다(작업은 「실행 중」인데 아무 일도 안 일어난다. 결과코드 267009). · Register-ScheduledTask 는 UserId 를 이름으로 주면 0x80070534, SID 로 줘도 0x80070057 로 죽었다. schtasks 가 답이다.
🔴결과 파일을 type 으로 읽지 마라 — 경로에 한글이 있으면 콘솔 코드페이지에서 깨져 「JSON 파싱 실패」로 오진한다. scp 로 받아 로컬에서 utf-8-sig 로 읽는다.
🔴ps1 은 UTF-8 BOM 필수(이미 아는 규칙인데 또 밟았다). BOM 없이 한글이 들어가면 PS5.1 이 cp949 로 읽어 한글 바이트가 따옴표를 깨먹고 「문자열 종결자 없음」으로 죽는다. 증상이 엉뚱해서 원인이 안 보인다.
캐드를 닫을 땐 taskkill 금지 — Document.Save() → Document.Close($false) 순서면 「저장하시겠습니까?」가 아예 안 뜬다. 이름 없는 새 도면(Drawing1)만 저장 없이 닫는다(Save 가 「다른 이름으로」를 띄워 자동화가 멈춘다).
읽기전용은 닫기 전 상태 그대로 되살린다 — 같은 DWG 를 두 PC 에서 열면 뒤에 연 쪽이 읽기전용이 된다. 그건 그 PC 의 사정이지 우리가 강제할 값이 아니다.
잠긴 DLL 교체는 「캐드가 닫힌 그 순간」이 유일한 기회 → 무인 시나리오에선 .dll.new 를 미리 깔아 두고 그 스크립트가 직접 Move-Item 한다(코디 세션이 그때 살아 있으리란 보장이 없다).

🆕 신규 — 사무실PC→미니PC `\100.108.234.45\dev` 는 계정명이 `POIN-MINI\delix` (26.9.7)

증상 = 사무실PC(poinimos01)에서 미니PC dev 폴더 접속 불가. 미니PC 설정은 전부 정상이었다 (공유 dev Everyone Full · NTFS Authenticated Users Modify · LanmanServer Running · 445 0.0.0.0 LISTEN · 방화벽 SMB-In(제한적) Private+Public/Remote=Any · Tailscale 인터페이스 프로필 Private · 445 TCP 도달 True).

🔑판정은 미니PC Security 로그 4625 한 방 — 사무실PC IP 에서 온 실패의 SubStatus 0xc0000064 = 「그런 사용자 없음」 (0xc000006a 였다면 비번 오류). 시도된 이름 = poinpc(사무실PC 로그인계정 = 패스스루 자동시도) 와 delix0731(구글/테일스케일 아이디). 미니PC 로컬계정은 delix 하나뿐 — 셋 다 다른 이름이라 인증 자체가 시작도 안 됐다.

# 미니PC 에서 원인 판정 (한 줄)
Get-WinEvent -FilterHashtable @{LogName='Security';Id=4625;StartTime=(Get-Date).AddDays(-3)} |
  %{ $d=@{}; ([xml]$_.ToXml()).Event.EventData.Data|%{$d[$_.Name]=$_.'#text'}; "$($_.TimeCreated) user=$($d['TargetUserName']) ip=$($d['IpAddress']) sub=$($d['SubStatus'])" }

처방(사무실PC 에서 1회) = cmdkey /add:100.108.234.45 /user:POIN-MINI\delix /pass → 비번 입력. 탐색기로 할 땐 \100.108.234.45\dev → 자격증명 창 사용자 이름에 POIN-MINI\delix 를 반드시 붙여서(도메인 없는 워크그룹이라 이름만 쓰면 사무실PC 로컬계정으로 해석된다).
⚠SSH 로는 이 증상을 재현·검증할 수 없다 — Session 0 라 net use/UNC 가 무조건 오류 67(메모리 ssh-session0-unc-always-error67), Test-Path '\...' 도 무조건 False. 그래서 클라이언트 쪽을 찌르지 말고 서버 쪽 4625 를 읽는 게 유일한 정공법이다.
관련: WG 철거(26.8.27)로 경로가 \10.73.241.2\dev → \100.108.234.45\dev 로 바뀌면서 옛 IP 로 저장돼 있던 자격증명이 무효가 됐다. 방화벽 SMB-WireGuard-10.73.241(Remote=10.73.241.0/24) 은 지금 아무 일도 안 하는 잔재다(제거는 페페 승인 사항).

🆕 신규 — 사무실PC 「엑셀 붙여넣기·시트복사에서 테두리·병합이 빠진다」 진단 순서 + SSH 스크립트 함정 (26.9.10)

🔑엑셀 이상은 로그 3개로 「언제부터」를 먼저 잡는다(전부 SSH 읽기전용, 엑셀이 꺼져 있어도 된다) 1. OAlerts — 엑셀이 띄운 대화상자 원문 + P2 = 그때 돌던 엑셀 빌드. 빌드가 바뀐 첫 시각 = 업데이트 뒤 첫 실행. 2. Application Id 1000 — EXCEL.EXE 크래시(빌드·오프셋). 60일치를 빌드별로 세면 「어느 빌드부터」가 나온다. 3. MsiInstaller Id 1022/1025/1029 — 어떤 KB가 언제 깔렸는지 · 「파일 사용 중(EXCEL)」 · 「다시 시작 연기」. 실측 = 9/9 12:38 KB5002914(엑셀 2016, 16.0.5569.1003)가 엑셀이 켜진 채로 설치됐고 재시작은 연기됐다 → 9/10 07:57 첫 실행 → 같은 날 신고. MS Q&A 에 같은 빌드에서 복붙이 안 되는 사례 2건(크래시형 · 「서식 없이 텍스트로만」형).
⚠MSI 오피스 2016 패치는 「프로그램 추가/제거」에 항목이 없을 수 있다(Uninstall 키에 KB5002914 0건). 실물은 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\<압축GUID>\Patches\<압축GUID> 에 있다. Uninstallable(1=제거 가능) · State(1=적용 중, 2=대체됨)를 본다. 제거 = msiexec /package {90160000-0011-0000-1000-0000000FF1CE} /uninstall {패치GUID} /qn /norestart. 판정은 rc 가 아니라 State·레지스트리로 한다(위 「프로그램 제거 함정 2」).
🔴ssh -T <host> powershell -Command - < x.ps1 는 여러 줄 블록(ForEach-Object { 뒤 줄바꿈)에서 첫 출력 뒤 조용히 멈춘다 — 에러가 0이다. 한 줄 문장만 있는 스크립트는 된다. 여러 줄이면 scp → -File → 삭제를 한 명령으로 묶는다.
곁가지(무죄 확인): 세션1의 마크애니(macourtsafer·MaEPSBroker) · 안랩 Safe Transaction · SmartKMLink 는 수년 전에 설치됐고 9/7 부팅 때부터 상주라 시점이 안 맞는다. 엑셀 WER 로드모듈에 주입 흔적도 없다(외부 DLL = nView nViewH64.dll 뿐). SmartKM 케이블은 미연결.
✅제거 실측(26.9.10 17:18~17:55 KST, SYSTEM 예약작업) 1. D:\_cody_MSOCache → C:\MSOCache 복원. 89파일 952,313,991B 대조했고 D: 사본은 유지. 2. 제품 6개를 순서대로 msiexec /uninstall {27882596-A8ED-4382-9C71-6CD2DD19F732} /package {제품코드} /qn /norestart 로 돌렸다. ProPlus 는 3010(재부팅 필요), 나머지는 0. 3. 판정 = 레지스트리 KB5002914 등록 0 · KB5002903 State=1(6개 전부) · EXCEL.EXE 16.0.5565.1001 · MSI 로그 6개 Return value 3 0건.

재설치 차단 = SYSTEM 으로 Microsoft.Update.Session → CreateUpdateSearcher() 를 만든다. ServerSelection=3 + ServiceID='7971f918-a847-4430-9279-4a52d1efe18d'(Microsoft Update — 이걸 안 주면 오피스 업데이트가 안 보인다)로 Search("IsInstalled=0 and IsHidden=0") 한 뒤, 제목에 KB 번호가 든 항목에 IsHidden=$true. 실측 70초 · 후보 17 · 숨김 1.

소요 37분 중 33분이 「없는 옛 패치」 원본 탐색이었다(위 9/2 정정 절의 SearchOrder=n 으로 해결). ✅[페페] 26.9.10 재시험 OK — 원인 = KB5002914 확정. - 🔴cmd 에서 괄호 없는 if exist X del X & 다음명령 은 & 다음명령 까지 if 본문이 된다. X 가 없으면 뒤 명령이 출력 0으로 통째로 건너뛰어진다(실측: 예약작업 생성이 조용히 안 됨). ⛒(if exist X del X) & 다음 처럼 괄호로 끊거나 if 를 뺀다. if … (…) else (…) & 다음 도 같다 — & 다음 이 else 쪽에 붙는다. - 오피스 패치 제거처럼 수십 분 걸리는 작업은 SSH 가 High 권한이어도 SYSTEM 예약작업(/RU SYSTEM, /IT 없음) 으로 돌린다. SSH 끊김·Bash 10분 한도에 안 걸리게 하려는 것이다. 완료 판정은 두 겹이다 — 스크립트가 모든 종료 경로에서 DONE 을 찍고, 미니PC 파이썬 폴러(셸 루프 금지)가 30초마다 그 파일을 본다.

🆕 신규 — 「지워도 살아나고 공유기 포트가 저절로 생긴다」 = 자동시작 서비스 + UPnP 재등록 (26.9.10, HGridEngine)

🔑판정 3단(전부 읽기) — ①Win32_Process 부모가 services.exe 면 서비스다(「지워도 생김」 = 서비스가 exe 를 잠가 삭제가 안 된 것) ②폴더 생성시각으로 재설치 여부를 가른다(HGrid = 2024-01-31 그대로 → 재설치 아님) ③공유기 매핑은 원격기 자신에서 (New-Object -ComObject HNetCfg.NATUPnP).StaticPortMappingCollection — 설명·내부IP 까지 나오고 SSH(Session 0)에서도 된다, 공유기 관리자 로그인 불필요. 같은 COM 의 .Remove(port,'TCP') 로 삭제도 된다.
🔑막을 땐 파일이 아니라 이름으로 막는다 — IFEO Debugger 를 없는 경로로 두면 그 이름의 exe 는 어느 폴더에 깔려도 CreateProcess 가 「파일 없음」으로 실패한다(서비스 기동 포함). 64비트 키에 쓰면 WOW6432Node 에도 같은 값이 보인다(공유 키). ⛒검증은 무해한 exe(whoami)를 그 이름으로 복사해 실행 → 막히면 PASS. 진짜 adware 로 시험하지 마라(뚫리면 그대로 돈다).
「감시 프로세스를 띄워 달라」 = 상주 대신 SYSTEM 예약작업(부팅+10분, 손댄 게 있을 때만 로그) — 26.9.4 「상주 0」 지시와 맞는다. 실물 = C:\dev\tools\hgrid-block\(guard·install·verify·unblock).
⚠원격 기본셸이 cmd.exe 라 ssh host powershell -Command "… | % {…}" 는 %·| 를 cmd 가 먹는다(「'%'은(는) 내부 또는 외부 명령이 아닙니다」) → 한 줄 조회도 .ps1 → scp → -File(위 항목과 같은 결론).
⚠드로퍼를 찾는다고 Get-ChildItem C:\Users\*\AppData\Local -Depth 1 을 돌리면 무한재귀로 멈춘다 = rules/tooling.md 🆕 26.9.10.
🔑「Tailscale 이 UPnP 를 쓰니 열어둬야 하지 않나」 판정법(26.9.10 실측) — ①그 PC 에서 tailscale netcheck → MappingVariesByDestIP: false 면 easy NAT 라 UPnP 없이도 홀펀칭으로 직결된다 ②tailscale ping <그 PC> 의 via <공인IP>:<포트> 포트가 UPnP 매핑표에 없으면 지금도 UPnP 없이 직결 중(실측 42969 · 표에 없음 · 4ms). 최악이어도 DERP(도쿄 35ms)로 자동 우회 — 끊기지 않는다.
⛔사무실 공유기 UPnP 를 통째로 끄지 마라 — CCTV 원격보기가 끊긴다. 192.168.0.80 = CCTV 녹화기(「HCMSActiveX Viewer」·eznetdns.com), 8602·8702 매핑이 그것. 끄려면 먼저 그 둘을 수동 포트포워딩으로. 원치 않는 매핑은 설명(Description) 패턴으로 골라 지운다(\Cody\HGridGuard 의 $drop = HGRID|nas200_).

🆕 신규 — 「사무실PC 인터넷이 이상하다」 = 두 PC 로그 교차대조로 PC냐 공용장비냐 가른다 (26.9.11)

🔑판정 한 방 = poinimos01·poinimos02 System 로그의 e1dexpress/27(링크 끊김)·DNS-Client/1014(DNS 시간초과) 시각이 겹치면 PC 가 아니라 공유기·허브·회선이다. 26.9.11 실측 = DNS 15:20:29 / 15:20:34, 링크 15:35:4x·15:36:4x 두 PC 동시. poinimos02 는 poinimos01 서브넷 라우트 경유라 poinimos01 이 살아난 뒤에만 닿는다.
🔴밖에서 본 공인IP 핑·포트포워딩으로 「회선 정상」 판정 금지 — 15:30 미니PC→112.170.234.238 핑 60/60·CCTV 8602/8702·AnyDesk 49438 OPEN 이던 그 시각에 안쪽 PC 들은 DNS·Tailscale 제어서버 둘 다 못 나갔다(공유기가 밖→안은 되고 안→밖은 안 되는 먹통). 사무실PC 재부팅으로도 안 풀렸고 공유기/허브 재시작 뒤 풀렸다.
끊긴 동안의 사무실PC 증거 = C:\ProgramData\Tailscale\Logs\*.txt 의 fetch control key … context deadline exceeded(나가는 통신 불가) · LinkChange: all links down. 미니PC 쪽 증상 = tailscale status 에 relay "tok" + Addrs: None + tailscale ping 무응답(Online 은 True 로 남는다 — 믿지 마라).
공유기 재부팅 흔적 = 밖에서 UPnP 포트(8702·49438)가 닫혔다가 몇 분 뒤 다시 열린다(UPnP 표가 비워진 것). ⚠SSH(Session 0)에서 SSDP M-SEARCH·HNetCfg.NATUPnP 조회는 응답 0 이 나왔다 → 공유기 가동시간은 이 경로로 못 잰다(관리화면 로그인 = 페페).
✅원격 PowerShell 은 ssh host powershell -NoProfile -Command - <<'PS' … PS(stdin) 로 넣으면 cmd 가 %·| 를 안 먹는다 — 위 「.ps1 → scp」 없이 여러 줄 조회가 됐다(한글 출력 = 첫 줄 [Console]::OutputEncoding=[Text.Encoding]::UTF8, 스크립트 본문엔 한글 금지).

🆕 신규 — 사무실PC 상주 최적화 (26.9.15) · 뱅킹 보안 SW 자가보호 벽

🔴🔑AhnLab Safe Transaction·nProtect Online Security 는 관리자로도 자동시작을 못 끈다 — sc config SafeTransactionSVC start= demand → OpenService FAILED 5: Access is denied, nossvc → ChangeServiceConfig FAILED 5. 지운 Run 키(AhnLab Safe Transaction Application)도 몇 초 만에 스스로 되살린다. 범인 = AhnLab 커널 필터 드라이버 3종(AHAWKENT.sys·TfFRegNt.sys(파일·레지스트리 필터)·ATamptNt.sys)의 self-protection. SYSTEM 승격(el.py)으로도 안 된다 — 유일한 길은 「설정 > 앱」에서 제거(은행 사이트 들어가면 다시 설치 유도되니 되돌리기는 사실상 무료). 나머지 13종(Veraport·Delfino·MagicLine·AnySign·IPinside·D'Amo·MarkAny·SKCert·CrossEX·INISAFE·Kings·Kollus·Interezen)은 평범하게 꺼진다.
⚠한국 뱅킹 보안 SW 의 무인제거(/S)는 대부분 실패한다 — NSIS/InstallShield 라 Session 0 에서 GUI 다이얼로그를 보이지 않는 데스크톱에 띄우고 멎는다(nProtect Netizen = 150초 타임아웃 kill). exit code 0 이 떠도 제거 안 된 경우가 흔하다(Kollus·Kings·INISAFE SandBox = 0 인데 STILL INSTALLED) — 반드시 Uninstall 레지스트리 재조회로 검증할 것. 성공한 건 Inno Setup 짜리 하나뿐(unins000.exe /SILENT = Delfino 2.1.4.3). → 제거는 페페 클릭 몫(설정 > 앱), 코디 몫은 자동시작 끄기까지.
✅실측 효과(26.9.15 00:43~00:49, 재부팅 1회 포함) — 프로세스 342 → 255, 실행 서비스 168 → 153(자동 126 → 111), 여유 RAM 21.2 → 25.4GB, 뱅킹 상주 15 → 5(자가보호 2종 계열만 잔존), C: +1.3GB. 부팅 이력(Diagnostics-Performance 100) = 직전 3회 80~105초.
🔑크롬 확장을 「끄는」 지원되는 방법 = 정책 레지스트리. Secure Preferences 손대면 HMAC 깨져 프로필이 초기화된다 → HKLM\SOFTWARE\Policies\Google\Chrome\ExtensionSettings\<id>\installation_mode = blocked. 되돌리기 = 그 키 삭제.
📁되돌리기 = C:\ProgramData\cody-officeopt\restore.ps1(Run 키 3개 .reg · 서비스 StartMode CSV · 시작폴더 .lnk 원본 보관). 적용본 = 같은 폴더 apply.ps1, 진단 스크립트 11개 = scripts\.
⚠Session 0 에서 크롬 기동시간 벤치는 무의미 — Start-Process chrome 이 창을 못 만들고 바로 죽는다(메모리 gui-test-needs-interactive-session 과 같은 뿌리). 체감 판정은 페페에게 맡기거나 schtasks /IT 로 Session 1 에서 잰다.
🆕사무실 공유기 = 신형 ipTIME(Flutter/JSON-RPC) — 관리페이지 로그인 자동화 정리(26.9.16). ①미니PC 는 tailscale 서브넷 라우트(poinimos01 이 192.168.0.0/24 광고)로 http://192.168.0.1 에 직접 200 도달. ②저장 자격 = 사무실PC(poinpc) Edge 프로필에 192.168.0.1/sess-bin/login_session.cgi :: poin912 가 v10 로 저장(Chrome 은 v20 app-bound 라 DPAPI 만으론 복호화 불가) → 사무실PC 에서 ctypes DPAPI 로 Local State 의 os_crypt.encrypted_key + blob 만 뽑아(무설치) 미니PC(cryptography)에서 AES-GCM(v10=blob[3:15]nonce+blob[15:]) 복호화. ③API = /cgi/service.cgi JSON-RPC 2.0(method 는 슬래시 네임스페이스: session/login·session/info·captcha/new·port/link/status·wan/heartbeat·network/info). 로그인 필수 param = flat {id,pw,captcha}(에러 -31997 data 가 알려줌). 캡차는 captcha/new→gif(200×70 단일프레임) → gemini OCR 정확(육안 대조 확인). 🔴미해결 = session/login 이 오답캡차·틀린pw·정답+실제pw 셋 다 값과 무관하게 -32602 — 서버가 세션 쿠키를 아예 안 줘서(/ui/·captcha/new 모두 Set-Cookie 없음) 캡차 제출을 발급분으로 못 잇는 세션/전송 계층 벽. 마지막은 실브라우저 로그인 요청 1건 캡처 필요. 도구 = C:\dev\tools\officewan-watch\router_wan.py(자격 blob 은 세션 scratchpad blob.json, 사무실PC 추출 스크립트는 쓰고 삭제).
🆕미니PC → poinimos01 ssh 를 스크립트에서 부를 땐 Git ssh 를 쓴다(26.9.16 실측) — C:\Windows\System32\OpenSSH\ssh.exe 는 echo hi 조차 응답 없이 멈춘다(BatchMode·ConnectTimeout 무관, 45초 타임아웃). C:\Program Files\Git\usr\bin\ssh.exe 는 즉시 반환 — 같은 ~/.ssh/config·같은 키인데 클라이언트만 다르다. 비대화형이면 -n + stdin=DEVNULL 도 같이 준다(원격 명령이 끝나고도 stdin 을 물고 대기하는 걸 막는다). 실물 = C:\dev\tools\officewan-watch\watch.py
⛒남은 것 = ①AhnLab ST·nProtect 제거 여부(페페 판단) ②옛 보안 SW 5종 GUI 제거(nProtect Netizen v5.5·Kollus Player v3·Kings Online Security·INISAFE SandBox·XecureWeb UnifiedPlugin) ③Windows\Installer 고아 MSI 8.9GB ④GPU 드라이버 2021/2022(Quadro K2200 + Intel HD 530, DWM 「video memory thrashing」 이벤트 4회) ⑤정체불명 서비스 Servr_Agent = C:\Program Files (x86)\Microsoft SQL Server\Servr_Agent.exe — MSSQL 정식 서비스명이 아니다, 확인할 것.