Question 1

데몬이 실행 중이 아닐 때 Windows에서 bsk 명령(browsers, status, session start)이 무한히 멈추는 이유는 무엇인가요?

Accepted Answer

이것은 Windows에서 bsk CLI 0.3.0의 알려진 버그입니다: 자동 데몬 시작 경로가 파이프로 연결된 stderr를 사용해 중간 `bsk daemon start`를 실행했고, 분리된(detached) 데몬이 해당 파이프(및 호출자의 파이프들)를 상속했습니다. 그 결과 데몬 자체는 성공적으로 시작되었음에도 불구하고 EOF가 도착하지 않아 대기 중인 클라이언트가 영원히 블록되었습니다.

**수정:** bsk CLI 0.3.1 이상으로 업그레이드하세요(수정 사항은 PR #282에 병합되었습니다). 이제 자동 시작은 캡처된 파이프 없이 데몬을 직접 생성하고, 단일 제한 데드라인으로 IPC 준비 상태를 기다리며, Windows에서는 PROC_THREAD_ATTRIBUTE_HANDLE_LIST를 통해 핸들 상속을 제한한 상태로 데몬의 stdio를 NUL로 지정합니다. `bsk update`를 실행하거나 공식 `install.ps1`로 재설치한 후 `bsk --version`으로 확인하세요.

**0.3.0에서의 해결 방법:** 다른 명령을 실행하기 전에 데몬을 수동으로 시작하세요: `bsk daemon start`(약 190ms 만에 반환). 그러면 이후 명령들이 정상적으로 작동합니다. 또는 `BSK_AUTO_START=0`을 설정하면 콜드 명령이 멈추는 대신 조치 가능한 오류와 함께 빠르게 실패합니다(exit 2, 약 86ms).

Question 2

Windows에서 'detects_hermes_from_home_layout' 및 'skills_dirs_match_harness_spec' 테스트 실패를 해결하는 방법

Accepted Answer

최신 `main`으로 업데이트하세요 — 이 문제는 업스트림에서 커밋 `47f5765`로 수정되었습니다 (PR #310을 통해 머지됨). 두 개의 `skill_install::harness` 테스트는 POSIX `~/.hermes` 레이아웃을 잘못 가정했지만, 리졸버는 업스트림 Hermes 관례를 반영하여 네이티브 Windows에서는 의도적으로 `%LOCALAPPDATA%\hermes`를 사용합니다 (`HERMES_HOME`이 설정된 경우에는 해당 값 사용). 이 수정은 어서션을 완화하는 대신 리졸버와 테스트를 함께 업데이트했습니다. 다음 명령을 실행하여 수정 사항을 확인하세요: `cargo test -p bsk --lib --locked skill_install::harness` — 네이티브 Windows에서 11개 테스트가 모두 통과해야 합니다. 이 실패는 `LOCALAPPDATA` 환경 변수의 존재 여부에 따라 브랜치가 선택되기 때문에 네이티브 Windows에서만 발생하며, 이전에는 CI가 Ubuntu에서만 전체 워크스페이스 테스트를 실행했습니다.

Question 3

BrowserSkill 에이전트 세션 중 높은 GPU/CPU 사용량을 해결하는 방법(컨트롤 오버레이 리페인팅 및 Accessibility 도메인이 활성화된 상태로 남아 있는 문제)?

Accepted Answer

두 가지 원인이 에이전트가 유휴 상태일 때도 브라우저를 바쁘게 만듭니다: (1) ControlOverlay가 무한 `box-shadow` 애니메이션(`bsk-breathe`)을 실행하는데, 이는 컴포지터에서 애니메이션 처리할 수 없으므로 매 프레임마다 전체 뷰포트가 다시 그려집니다. (2) 모든 `observe`/`snapshot`이 CDP `Accessibility.enable`을 전송하지만 `Accessibility.disable`은 전송하지 않아, 세션이 끝날 때까지 렌더러의 접근성 트리가 활성 상태로 유지됩니다.

빠른 해결 방법: 확장 프로그램 팝업에서 "Control hints"를 끄세요 — 이렇게 하면 오버레이 리페인트만 중단됩니다(Accessibility는 활성화 상태로 유지됨).

완전한 수정(PR/패치로 제공, MIT): 무한 그림자 애니메이션을 정적 인셋 그림자와 두 사이클짜리 컴포지터 전용 `opacity` 펄스로 교체하고(`prefers-reduced-motion: reduce` 환경에서는 건너뜀), 각 캡처가 AX 트리 읽기를 마친 후 캡처 워커 풀을 통해 완료된 각 타겟에 `Accessibility.disable`을 전송합니다. Chromium 153/Chrome for Testing 154에서 측정한 결과: 세션 중 GPU 프로세스 사용량이 코어의 ~20.5%에서 ~5.6%로 감소했고(-73%), 브라우저 전체 CPU 사용량은 ~35.4%에서 ~12.5%로 감소했습니다(-65%).

Question 4

'Plugin @wxg-prc-cpg/browser-skill-dsh-plugin is incompatible with dsh 0.2.0' 오류 해결 방법 (플러그인이 건너뛰어지고 browser_* 도구가 누락됨)

Accepted Answer

원인: `@wxg-prc-cpg/browser-skill-dsh-plugin@0.3.1`(현재 npm latest)이 harness peerDependencies를 `^0.1.5-rc.3`만 선언하므로, DSH 0.2 호스트는 `dsh plugin add` 시 이를 거부하고 부팅 시 조용히 건너뜁니다. Web UI는 로드되지만 6개의 `browser_*` 도구가 전혀 등록되지 않습니다. 해결 방법: 정확한 버전 예외를 부여하여 강제로 로드합니다(작동 확인됨):

```
dsh plugin --profile web allow-version @wxg-prc-cpg/browser-skill-dsh-plugin@0.3.1 --dsh-version 0.2.0-rc.2 --accept-risk
```

`--dsh-version`을 호스트 버전에 맞게 조정하세요(예: `0.2.0-rc.1`). 영구 수정: peer 범위 `|| ^0.2.0-rc.1`은 이미 `main`에 병합되었지만(커밋 `bf5a8d96`) 아직 게시되지 않았습니다. 0.3.1보다 새로운 플러그인 릴리스를 기다렸다가 게시되면 `dsh plugin add @wxg-prc-cpg/browser-skill-dsh-plugin@latest`로 업그레이드하세요.

Question 5

DSH 0.2.0+에서 오른쪽 사이드바 observation 탭이 자동으로 열리지 않는 이유는 무엇인가요?

Accepted Answer

근본 원인: 업스트림 `@deepseek-ai/dsh-api-session-controller`가 0.2.0-rc.2에서 `sessions.list`의 `current` 필드를 제거했습니다 (0.1.5-rc.3에는 여전히 `createSnapshotStore({... current ...})`가 있었습니다). `lib/client.cjs`의 플러그인 자동 열기 로직은 `sessions.list.getSnapshot().current`를 읽는데, 이 값이 이제 항상 `undefined`이므로 `current !== sessionId`가 항상 true가 되어 자동 열기 경로가 조용히 취소됩니다. 탭 등록이 `current`에 의존하지 않기 때문에 수동 열기는 여전히 작동합니다. 수정: 클라이언트를 패치하여 자동 열기 대상을 대신 관측 데이터에서 파생하도록 합니다 — 각 관측에는 `dshSessionIds`가 포함되어 있으므로 `visibleToScope(obs, id) = obs.dshSessionIds.includes(id)`를 사용하고, `attempt()`의 엄격한 `current` 확인은 `current`를 사용할 수 있을 때만 유지합니다. 임시 해결 방법: DSH를 0.1.5-rc.3으로 다운그레이드하거나 오른쪽 사이드바 페이지 목록에서 관측 탭을 수동으로 여세요.

BrowserSkill

주요 기능

할 수 없는 것

사용 사례

태그

시작하기

유사한 프로젝트