Bohdan Triapitsyn
a5aa32446d
The preview panel worked by proxying a dev server through OpenChamber's own origin and rewriting the HTML that came back. Anything the rewriter did not anticipate broke, and pages that refuse to be embedded never loaded at all. This deletes the proxy (-1604 lines and its tests) and merges the preview and browser panels into one surface backed by a real Chromium view. What the panel is now - A `<webview>` in its own session partition: logins and cookies persist, hot reload works because nothing is rewritten, DevTools are one click away. - Annotation: pick one element, drag a region, or draw freehand, write a note, and it reaches chat with a screenshot of the visible page with the marks on it. - Toolbar: hard reload, page zoom, device sizes, a light/dark switch that applies to the page rather than the app, and cookie/cache clearing scoped to the panel alone. - Several pages at once, each tab showing the page's own favicon, and an address bar that suggests pages already visited in this project. - Dev servers are listed from what is actually listening on the machine, checked against what a project announced, so a server is offered no matter how it was started. One that is still starting is waited for instead of failing. Remote dev servers The desktop app binds a local port and pipes raw bytes to the OpenChamber host over the existing authenticated connection, so the page keeps its own origin at the root of its own host. The reachable set is exactly what discovery reports and is re-checked per connection, so an authenticated client cannot dial arbitrary local services on the host. Links and redirects to another loopback port stay on the machine that served the page. A tunnel that cannot be opened is reported; it is never replaced by the plain loopback URL, which would answer from the user's own machine under a remote address. Agent control Browser actions are a separate `openchamber_web` tool: open, snapshot, click, type, scroll, inspect computed styles, resize between mobile/tablet/desktop, and capture a screenshot into `.openchamber/screenshots/` in the project. The existing `openchamber` tool keeps sessions, worktrees and scheduled tasks. Each has its own setting in the new Settings -> General -> OpenChamber Tools section, and the plugin is not injected at all when both are off. Capability belongs to the connected client, not to configuration: a client declares on its event stream that it can drive a page, which only a Chromium host does. Exactly one client performs each request — it claims the request before acting, and the first claim wins — because deciding by whose result arrives first would be too late for a click that already happened. No client listening is answered immediately with an explanation rather than a timeout. Runtime boundaries Web tabs get a plain iframe that can display a page but not inspect one. The VS Code extension no longer offers the surface at all, since nothing that makes the panel worth having works there. Mobile is unaffected. Native boundary Camera, microphone, location and device-picker requests from panel pages are denied — Electron grants them by default when no handler is set, and the panel loads whatever address the user types. Page capture, appearance emulation and storage clearing verify that their target belongs to the panel's own session instead of trusting a web-contents id from the renderer. Persisted state Stored `preview` tabs migrate to `browser` (v13 -> v14). Context panel tab limits are now per surface, so filling one surface no longer evicts another's tabs. Address history is stored per project and per runtime. Documentation `preview.mdx` and `desktop-browser.mdx` rewritten across all locales, the agent tool settings path corrected, new `DOCUMENTATION.md` for the browser-control broker and the dev tunnel, and the `ui-api-decoupling` skill updated where it still described the deleted proxy.
41 lines
3.5 KiB
Plaintext
41 lines
3.5 KiB
Plaintext
---
|
|
title: エージェント制御ツール
|
|
description: エージェントがチャットから OpenChamber のセッション、worktree、スケジュールタスクを管理できるようにします。
|
|
---
|
|
|
|
# エージェント制御ツール
|
|
|
|
`openchamber` エージェントツールを使うと、チャットからアプリ内の作業を直接管理できます。OpenChamber が独自のローカル OpenCode サーバーを実行している場合はデフォルトで有効になり、別のツールのインストールや shell コマンドの実行は必要ありません。
|
|
|
|
## 依頼できること
|
|
|
|
自然な言葉でエージェントに依頼します。例：
|
|
|
|
- 「このプロジェクトに新しい OpenChamber セッションを作成し、`openai/gpt-5.6-sol` モデルを使って次のプロンプトを送信して：認証フローをレビューして。」
|
|
- 「このタスク用の新しい OpenChamber セッションを別の worktree に作成し、ログインフローのテストを追加するよう依頼して。」
|
|
- 「OpenChamber を使って最近のセッション 10 件とそれぞれの現在の状態を表示して。」
|
|
- 「OpenChamber に平日レビューというスケジュールタスクを作成し、平日の 09:00 に次のプロンプトを送信して：前回の実行以降の変更をレビューして。」
|
|
- 「平日レビューという OpenChamber スケジュールタスクを今すぐ実行して。」
|
|
- 「認証レビューという OpenChamber セッションを確認し、最新のアシスタント応答を表示して。」
|
|
|
|
このツールは、プロジェクトとモデル設定の一覧表示、セッションの作成と継続、セッションのフォーク、分離された worktree セッションの作成、スケジュールタスクの管理を行えます。この方法で開始したセッションも通常のセッションと同じように OpenChamber に表示されるため、自分で開いて作業を続けられます。
|
|
|
|
## 注意点
|
|
|
|
- 新しいセッションへのプロンプトは、デフォルトではすぐに処理を返します。OpenChamber でセッションを確認するか、後でエージェントに結果を確認するよう依頼してください。
|
|
- 別の worktree は、明示的に依頼した場合にのみ作成されます。現在の worktree にある未コミットの変更はコピーされません。
|
|
- このツールは、セッションや worktree の削除、プロジェクトパスの登録、任意の shell コマンドの実行、任意の URL の呼び出しはできません。
|
|
|
|
## ツールを有効または無効にする
|
|
|
|
**設定 → 一般 → OpenChamber ツール** を開き、**エージェント制御ツール**を変更します。この設定は、管理対象の OpenCode サーバーが再起動すると反映されます。再起動は OpenChamber が **Apply & Restart** として案内します。
|
|
|
|
OpenChamber が `OPENCODE_HOST` または skip-start で外部 OpenCode サーバーに接続している場合や、VS Code 拡張機能内では、このツールを利用できません。OpenChamber が管理する OpenCode サーバーを使用するデスクトップ版と Web 版では自動的に利用できます。
|
|
|
|
## 関連項目
|
|
|
|
- [スケジュールタスク](/ja/scheduled-tasks/)
|
|
- [Worktree セッション](/ja/worktrees/)
|
|
- [セッションゴール](/ja/session-goals/)
|
|
- [ブラウザパネル](/ja/desktop-browser/) — ページを見て操作するための OpenChamber Web ツール
|