윈도우 터미널 폭주 원인 및 해결 방법 | OpenConsole과 에이전트 CLI

터미널 폭주가 뭔지

터미널 폭주는 “콘솔이 하나 더 열린다” 수준이 아니다. 같은 계열의 콘솔 프로세스가 짧은 간격으로 계속 생성되는 상태다. 화면에는 Windows Terminal 창이 쌓이거나, 작업 관리자에는 WindowsTerminal.exe와 OpenConsole.exe 개수가 빠르게 늘어난다.

정상 사용에서는 새 셸이 기존 창의 탭으로 붙거나, 백그라운드 자식 프로세스가 보이지 않는 콘솔로 돈다. 폭주 때는 그 두 조건이 깨진다. 새 인스턴스가 매번 새 창으로 붙고, 자식 프로세스에 숨김 플래그가 없어 기본 터미널 앱이 매번 화면을 연다.

핵심 포인트: 폭주의 본질은 “터미널 앱이 고장 났다”보다 누가 CreateProcess로 콘솔 자식을 반복 생성하는지에 가깝다. Windows Terminal은 그 자식을 보이게 만드는 마지막 층이다.

지금 당장 알아둘 것

증상만 보면 원인 후보를 좁히기 쉽다.

기본 터미널 앱이 Windows Terminal이면, 숨기지 않은 콘솔 자식은 대개 Windows Terminal 창으로 보인다. 기본값이 예전 Console Host면 conhost 창으로 보일 수 있다. Microsoft 문서에 따르면 기본 터미널 앱 설정은 Windows 11과 일부 Windows 10 22H2 이후에서 쓸 수 있다.

에이전트 창만 닫고 끝내면 안 되는 경우가 많다. 데몬이나 업데이터 대기 cmd가 살아 있으면 콘솔이 다시 열린다.

Windows가 콘솔을 띄우는 방식

Microsoft의 콘솔 생태계 문서에서 역할은 네 층으로 나뉜다. 클라이언트(cmd, pwsh, bash 같은 문자 모드 앱), 장치(ConDrv), 서버(콘솔 API를 해석하는 쪽), 터미널(화면과 입력).

전통 모드에서는 문자 모드 앱이 뜰 때 OS가 콘솔 호스트를 자동으로 붙인다. 지금 권장되는 ConPTY(의사 콘솔) 모드에서는 호스트 앱이 먼저 파이프와 CreatePseudoConsole으로 의사 콘솔을 만든 뒤, CreateProcess로 자식을 붙인다. 의사 콘솔 문서가 이 순서를 분명히 적는다.

GitHub microsoft/terminal 토론에서 메인테이너는 OpenConsole과 conhost가 같은 코드 계열이라고 설명한다. Windows 빌드 시스템으로 빌드하면 conhost가 되고, Terminal과 함께 배포되는 OpenConsole은 ConPTY 쪽에 더 가까운 최신 쪽이다. 그래서 폭주 때 OpenConsole.exe가 많이 보이는 것은 “이상한 악성 파일”이라기보다 ConPTY 세션이 많이 열린다는 신호에 가깝다.

Windows Terminal의 windowingBehavior 기본값은 문서상 useNew 다. wt나 기본 터미널 경로로 새 인스턴스가 붙을 때 항상 새 창을 만든다. useExisting 또는 useAnyExisting이면 기존 창에 탭으로 붙는다. wt -w -1은 새 창, wt -w 0은 최근 창이다. 폭주 상황에서 창 개수가 폭발하는 이유 중 하나가 이 기본값과 맞물린다.

반복되는 원인 패턴

Orca만이 아니다. 공개된 사례를 묶으면 패턴이 네 갈래로 모인다.

터미널 데몬이 자식을 숨기지 못하는 경우

로컬 코딩 에이전트용 터미널 데몬은 보통 Electron 또는 단독 node.exe 위에서 PTY를 연다. Orca 쪽 2026년 7월 커밋은 원인을 짧게 적는다. Electron에 묶인 Node는 windowsHide 기본이 true인데, 단독 node.exe 데몬은 기본이 false라서 child_process와 node-pty kill 경로의 콘솔 목록 에이전트가 몇 초마다 Windows Terminal 창을 열었다 닫는다.

같은 계열 문제는 node-pty 이슈와 ConPTY 호스트 패치에도 반복된다. GUI 서브시스템 부모가 콘솔이 없는 상태에서 ConPTY 자식을 만들면 Windows가 보이는 콘솔을 할당하는 경우가 있고, 기본 터미널이 Windows Terminal이면 그 창이 사용자 화면에 그대로 나타난다.

에이전트 훅이 Windows 파일 연결로 .sh를 여는 경우

Cursor 포럼(2026년 6월)에는 Agent 작업 중 외부 Git Bash 창이 수백 개 뜨는 보고가 있다. 스태프 답변에 따르면 postToolUse / afterFileEdit 훅이 캐시된 플러그인의 원시 .sh 경로를 가리키고, Windows는 그 경로를 Cursor 내장 셸이 아니라 파일 연결(Git Bash bash --login -i) 로 연다. 편집·툴 호출마다 훅이 돌면 창이 누적된다. IDE의 “Kill All Terminals”로는 안 닫힌다. 통합 터미널 탭이 아니라 외부 프로세스이기 때문이다.

cursor-agent 업데이터 대기 프로세스가 OpenConsole을 깜빡이는 경우

Cursor CLI(cursor-agent) Windows 이슈(2026년 10월)에서는 스테이지된 업데이트의 .pending.replace.cmd 대기 프로세스가 tasklist / find를 반복 호출하면서 초당 한 번 꼴로 콘솔이 깜빡인 사례가 있다. 강제 종료 뒤 남은 versions\\.running\ 마커, 재사용된 PID, OpenConsole.exe -Embedding 자식이 겹치면 수십 분 동안 이어질 수 있다. 스태프도 진단이 맞다고 확인했고, 에이전트가 없을 때 stale .running 마커를 지우고 pending cmd를 끊는 우회가 공유됐다.

시작 프로그램과 런너 스크립트가 재로그온마다 다시 켜는 경우

Startup 폴더의 .lnk는 대화형 로그온 때 실행된다. Microsoft 지원 문서의 shell:startup 경로는 %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup 이다. 여기에 터미널 데몬이나 에이전트 런너 바로가기가 남아 있으면, 재부팅으로 폭주를 “끊은” 것처럼 보여도 다음 로그인에 다시 시작된다. 프로젝트 폴더의 run.ps1 같은 러너가 Start-Process로 wt나 콘솔을 반복 호출하면, 사람이 의도한 한 번 실행이 루프가 된다.

2026년 10월 23일 사례에서 겹친 것

같은 날 Windows PC에서 관측된 폭주는 단일 원인이 아니었다. Cursor CLI(cursor-agent의 stream-json 출력 모드), ACP 호스트, 터미널 데몬(Orca daemon-host)이 겹쳤고, 화면에는 OpenConsole / Windows Terminal 창과 여러 봇 창이 함께 쌓였다.

중요한 관찰은 에이전트 프로세스만 종료해도 부족했다는 점이다. 데몬이 살아 있는 동안 콘솔이 계속 열렸다. 적용된 조치는 앱 제거, Startup의 Orca.lnk 삭제, 러너 run.ps1을 run.ps1.DISABLED-flood처럼 이름 바꿔 비활성화한 것이다. AppData\Roaming\orca 캐시 폴더는 바이너리 없이도 남을 수 있으나, 시작 바로가기와 실행 파일이 없으면 그 자체로 창을 만들지는 않는다.

이 사례에서 읽을 교훈은 단순하다. 폭주 중에는 “가장 눈에 띄는 창의 부모”와 “로그온마다 다시 켜지는 진입점”을 같이 끊어야 한다. 폭주가 났던 러너를 그대로 다시 켜는 안다는 재발을 부른다.

진단에 쓰는 명령과 경로

폭주가 한창일 때는 프로세스 수부터 본다.

Get-Process WindowsTerminal, OpenConsole -ErrorAction SilentlyContinue |
  Group-Object ProcessName |
  Select-Object Name, Count

부모-자식 관계는 작업 관리자 세부 정보에서 확인하거나, 필요하면 Process Explorer 같은 도구로 OpenConsole의 부모를 본다. 부모가 daemon-host, node, cursor-agent, cmd(pending.replace) 중 무엇인지가 갈린다.

시작 진입점은 폴더와 레지스트리를 같이 본다.

$startup = "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup"
Get-ChildItem $startup -Filter *.lnk | ForEach-Object {
  $s = (New-Object -ComObject WScript.Shell).CreateShortcut($_.FullName)
  [pscustomobject]@{ Name = $_.Name; Target = $s.TargetPath; Args = $s.Arguments }
}

Get-CimInstance Win32_StartupCommand |
  Select-Object Name, Command, Location, User

Cursor 쪽이면 Settings의 Hooks 목록에서 .sh로 끝나는 명령을 확인한다. cursor-agent면 %LOCALAPPDATA%\cursor-agent\versions 아래 .running 마커와 pending-launchers\*.pending.replace.cmd 존재 여부를 본다. 에이전트가 실제로 돌고 있지 않은데 마커만 많으면 업데이터 깜빡임 후보이다.

Windows Terminal 설정 UI의 Startup에서 Default terminal application, New instance behavior(windowingBehavior) 도 확인한다. 창이 탭 대신 창으로만 쌓이면 useNew와의 조합을 의심한다.

폭주가 난 순간에 끄는 순서

순서가 바뀌면 “닫았는데 또 뜬다”가 반복된다.

1. 새 창을 만드는 부모를 먼저 찾는다. 데몬, 업데이터 pending cmd, 훅을 쏘는 IDE/플러그인, 루프 중인 run.ps1 중 무엇인지 고른다.
2. 그 부모 트리부터 종료한다. 자식 OpenConsole만 클릭으로 닫으면 부모가 즉시 다시 만든다.
3. Startup .lnk와 자동 실행 런너를 제거하거나 이름을 바꿔 재진입을 막는다.
4. 그다음에야 남은 Windows Terminal / OpenConsole 잔여를 정리한다.
5. 재로그온 또는 재부팅 뒤 Get-Process로 개수가 다시 안 늘어나는지 확인한다.

하지 않는 편이 나은 것도 있다. 폭주 중인 러너를 “다시 한 번 실행해서 고치기”, 원인 불명인 채 taskkill /F /IM WindowsTerminal.exe만 반복하기, Startup 바로가기를 남긴 채 창만 닫기, stale 마커를 살아 있는 cursor-agent가 있는 상태에서 함부로 지르기(업데이트·세션 꼬임)다. Colin이 공유한 cursor-agent 우회도 에이전트가 없을 때 .running을 지우는 전제였다.

재발을 줄이는 설정과 습관

로컬 에이전트를 쓰는 Windows 환경에서 효과가 큰 쪽만 적는다.

Windows Terminal에서는 New instance behavior를 상황에 맞게 useExisting 계열로 두는 것을 검토한다. 기본 useNew는 의도된 동작이지만, 실수로 wt가 반복 호출되면 창 수가 바로 는다. 기본 터미널 앱을 무엇으로 둘지는 취향이지만, “숨기지 않은 콘솔 자식이 화면에 어떻게 보이는지”를 결정한다.

Cursor에서는 Hooks에 원시 .sh 경로가 있는지 본다. Windows에서는 .ps1 래퍼나 명시적 bash -c처럼 파일 연결을 거치지 않는 형태가 안전하다. 포럼에서 확인된 것처럼 deploy-on-aws 같은 이름과 무관하게 postToolUse가 매 툴 호출에 돌 수 있다. 에이전트마다 콘솔이 깜빡이면 "terminal.integrated.windowsUseConptyDll": true 설정이 거론된 바 있다. 버전별로 효과가 다를 수 있어, 적용 전후 창 생성 여부를 직접 확인하는 편이 맞다.

cursor-agent를 스크립트로 자주 돌리면 강제 종료 뒤 %LOCALAPPDATA%\cursor-agent\versions\*\.running\ 잔여와 pending-launchers를 점검한다. 정상 종료에서도 마커가 남는다는 후속 보고가 있어, CLI를 자동화에 넣는 환경에서는 마커 정리가 운영 절차에 들어간다.

프로젝트 런너는 한 번 실행하고 끝나는지, Start-Process로 wt를 루프하는지 코드를 읽는다. 폭주를 만든 러너는 비활성 이름(*.DISABLED-flood)으로 남겨 실수 재실행을 막는다. 터미널 데몬 앱을 쓰지 않는다면 Startup의 해당 .lnk를 제거한다. 캐시 폴더만 남은 것과 실행 파일·바로가기가 남은 것은 다르다.

마무리

앞에서 다룬 윈도우 터미널 폭주의 핵심만 짧게 정리한다.

• OpenConsole이 많이 보이면 ConPTY 세션이 많이 열린 신호로 읽는 편이 맞다
• Orca형 데몬, Cursor 훅 .sh, cursor-agent 업데이터 대기, Startup .lnk가 대표 반복 패턴이다
• 에이전트만 종료하고 데몬과 런너, 바로가기를 남기면 창이 다시 뜬다
• 끌 때는 부모, 시작 진입점, 잔여 콘솔, 재로그온 확인 순서가 안전하다
• 폭주를 만든 러너를 그대로 재활성화하지 않는다

「창을 닫기 전에, 창을 다시 여는 부모를 끊는다.」 로컬 에이전트 PC에서는 Startup, Hooks, .running 마커, windowingBehavior 네 곳을 주기적으로 보면 같은 사고가 덜 반복된다.

출처와 링크

조사 기준: 2026년 10월.

• Creating a Pseudoconsole session (Microsoft Learn)
• Windows Console and Terminal Ecosystem Roadmap (Microsoft Learn)
• Windows Terminal Startup Settings (Microsoft Learn)
• Windows Terminal command line arguments (Microsoft Learn)
• OpenConsole.exe vs conhost.exe (microsoft/terminal Discussion #12115)
• Configure Startup applications in Windows (Microsoft Support)
• Win32_StartupCommand (Microsoft Learn)
• Cursor Agent spawns hundreds of Git Bash windows
• Multiple cmd.exe windows on every AI request
• cursor-agent updater flashes console windows
• Orca: Hide console windows for node.exe-hosted daemon