新しい Show HN スレッドで、DenchClaw が公開された。このプロジェクトの狙いは、OpenClawを単なるagent runtimeとして使うのではなく、ローカル中心のCRM兼general productivity workspaceとして包み込むことにある。HNで反応を集めた理由は明快で、複数のcloud serviceをagentの周辺に足し込む代わりに、agent、browser、UI、local data layerを一つのシステムとしてユーザーのマシン上に置こうとしている点だ。

repoの説明を見る限り、onboardingは比較的シンプルだ。導入は実質 npx denchclaw で始まり、Node 22+ が必要、セットアップ後は localhost:3100 にweb UIが立ち上がる。内部では dench という専用のOpenClaw profileと19001番台のgatewayが作られ、既存のOpenClawコマンドを別のローカルworkspaceに向けて再利用できる。ここは重要で、DenchClawがOpenClawの代替品ではなく、その上に乗るopinionated layerとして設計されていることを示している。

より特徴的なのはデータとアプリのモデルだ。HNのlaunch文では、table filter、view、calendar、gantt layoutなどがすべてlocal file system上にあり、OpenClawがDenchのCRM skill経由でそれらを扱えると説明されている。またCRMの基盤にはDuckDBを採用したとされる。続くHNの議論では、その理由も補足されており、local-first workloadではサーバDBより運用が軽く、CRM規模のexportを十分処理でき、さらに大きめのファイルでもout-of-core executionが使いやすいという判断だ。

DenchClawは単なるローカルDBアプリよりも踏み込んでいて、ユーザーのbrowser自体をintegration surfaceとして使う。launch文によると、Chrome profileを複製して既存のログイン状態を引き継ぎ、HubSpotやNotionのようなサービスに直接入り、exportを起動し、ダウンロードしたファイルをローカルworkspaceへ取り込めるという。投稿者はこれを「Cursor for your Mac」に近いものだと表現しているが、file tree、browser access、CRM workflowが一体化している点が本質だ。

当然ながら、この設計はすぐに最も重要な質問を呼び込んだ。ログイン済みbrowserをagentが操作できるなら、誤操作をどう防ぐのかという問題だ。このShow HNが面白いのは、そのリスクを避けずに議論している点にある。コメント欄では、SaaSツール上でのunintended action、cookie conflict、個人のbrowser stateをLLMに委ねるtrust boundaryが大きな論点になった。これに対してmaintainerは、import skillはaction前にユーザー確認を求めるよう設計しており、browser経由のworkflowは実行中にユーザーが見て監督できると説明した。

DenchClawが実際にmainstreamなOpenClaw layerになるかはまだ分からない。ただ、このShow HNはlocal agent toolingの進化方向をよく示している。テーマはsales CRMそのものよりも、local UI、local file、軽量なanalytical store、そしてagentが実際に操作できるbrowserがあれば、多くのworkflowをremote SaaS wrapperの外へ移せるのではないか、という仮説の検証にある。

#crm

Show HN: DenchClaw、OpenClaw上にローカルCRMとbrowser-aware workspaceを重ねる