Question 1

デーモンが実行されていない場合、Windowsでbskコマンド（browsers、status、session start）が永遠にハングするのはなぜですか？

Accepted Answer

これは Windows 上の bsk CLI 0.3.0 における既知のバグです: 自動デーモン起動パスが、stderr をパイプ化した中間の `bsk daemon start` を起動し、デタッチされたデーモンがそのパイプ (および呼び出し元のパイプ) を継承したため、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` (約 190 ms で復帰)。これ以降のコマンドは正常に動作します。あるいは、`BSK_AUTO_START=0` を設定すると、コールドコマンドがハングする代わりに、対処可能なエラーとともに高速に失敗するようになります (exit 2、約 86 ms)。

Question 2

Windowsで'detects_hermes_from_home_layout'と'skills_dirs_match_harness_spec'のテスト失敗を修正する方法

Accepted Answer

最新の `main` に更新してください — この問題は上流のコミット `47f5765` で修正されています（PR #310 でマージされました）。2 つの `skill_install::harness` テストは、POSIX の `~/.hermes` レイアウトを誤って前提としていましたが、リゾルバーは意図的に、ネイティブ Windows では `%LOCALAPPDATA%\hermes`（設定されている場合は `HERMES_HOME`）を使用しており、これは上流の Hermes の慣習を踏襲しています。この修正は、アサーションを緩めるのではなく、リゾルバーとテストの両方を更新しました。次を実行して修正を確認してください：`cargo test -p bsk --lib --locked skill_install::harness` — ネイティブ Windows では 11 個すべてのテストがパスするはずです。なお、この失敗がネイティブ Windows でのみ発生するのは、`LOCALAPPDATA` 環境変数の有無によってブランチが選択されるためであり、以前 CI はワークスペース全体のテストを Ubuntu でのみ実行していたことにご注意ください。

Question 3

BrowserSkill エージェントセッション中に GPU/CPU 使用率が高くなる問題を修正する方法(コントロールオーバーレイの再描画と Accessibility ドメインが有効のまま残っている場合)?

Accepted Answer

エージェントがアイドル状態でもブラウザをビジーにし続ける原因が2つあります: (1) ControlOverlayが無限の`box-shadow`アニメーション(`bsk-breathe`)を実行していますが、これはコンポジターでアニメーション化できないため、フレームごとにビューポート全体が再描画されます。(2) すべての`observe`/`snapshot`がCDPの`Accessibility.enable`を送信しますが、`Accessibility.disable`は一度も送信されないため、レンダラーのアクセシビリティツリーがセッションの残りの間ずっと有効なままになります。

簡単な回避策: 拡張機能のポップアップで「Control hints」をオフにしてください。これによりオーバーレイの再描画のみが停止します(Accessibilityは有効なままです)。

完全な修正(PR/パッチとして提供、MIT): 無限のシャドウアニメーションを、静的なインセットシャドウと2サイクルのコンポジターのみで実行される`opacity`パルス(`prefers-reduced-motion: reduce`の場合はスキップ)に置き換え、各キャプチャがAXツリーの読み取りを完了した後、キャプチャワーカープール経由で完了した各ターゲットに`Accessibility.disable`を送信します。Chromium 153/Chrome for Testing 154での計測結果: セッション中のGPUプロセス使用率は1コアあたり約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）は、ハーネスの 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`）に合わせて調整してください。恒久的な修正: ピア範囲 `|| ^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+ では右サイドバーのオブザベーションタブが自動で開かなくなるのですか？

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 に依存しないため、手動でのオープンは引き続き機能します。修正方法: クライアントにパッチを適用し、自動オープンの対象を observation データから導出するように変更します。各 observation は dshSessionIds を保持しているため、visibleToScope(obs, id) = obs.dshSessionIds.includes(id) を使用し、attempt() の厳密な current チェックは current が利用可能な場合のみ維持します。回避策: DSH を 0.1.5-rc.3 にダウングレードするか、右サイドバーのページリストから observation タブを手動で開いてください。

BrowserSkill

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト