A fresh Show HN thread introduced DenchClaw, a project that tries to turn OpenClaw into a local-first CRM and general productivity workspace rather than just a raw agent runtime. The pitch that resonated on HN was simple: instead of wiring a stack of cloud services around an agent, package the agent, browser, UI, and local data layer into one system that lives on the user's machine.

The repo keeps the onboarding minimal. The install path is essentially npx denchclaw, with Node 22+ required, and after setup it opens a web UI at localhost:3100. Under the hood, DenchClaw creates a dedicated OpenClaw profile named dench and a gateway in the 19001 port range, so the same OpenClaw commands can be reused with a separate local workspace. That operational detail matters because the project is positioning itself as an opinionated layer on top of OpenClaw rather than a replacement for it.

The more distinctive part is the data and application model. In the HN launch text, the author says table filters, views, calendar and gantt layouts all live in the local file system, letting OpenClaw interact with them through Dench's CRM skill. The project also states that its CRM is built on DuckDB, and the HN discussion later expands on why: for local-first workloads, DuckDB offers a much simpler operational footprint than a server database while still handling CRM-scale exports comfortably, including out-of-core execution for larger files.

DenchClaw also pushes further than a typical local database app by leaning on the user's browser as an integration surface. The launch post says the app can copy a Chrome profile into its own environment so it can access already authenticated sessions, then drive imports from services such as HubSpot or Notion by navigating the browser, triggering exports, and ingesting downloaded files into the local workspace. The author even describes it as something like "Cursor for your Mac," but with a file tree, browser access, and CRM workflows wired in.

That approach immediately triggered the most important HN questions: if the agent can control a logged-in browser, what keeps it from doing the wrong thing? The thread is worth reading because it does not ignore the risk. Commenters raised concerns about unintended actions in SaaS tools, cookie conflicts, and the broader trust boundary of giving an LLM access to personal browser state. In response, the maintainer said import skills are designed to ask for user confirmation before actions and that browser-driven workflows remain visible and supervisable while they run.

Whether DenchClaw becomes a mainstream OpenClaw layer or not, the Show HN launch is a useful snapshot of where local agent tooling is going. The project is not only about sales CRM. It is testing a broader thesis that a local UI, local files, a lightweight analytical store, and a browser the agent can actually operate may be enough to move many agent workflows out of remote SaaS wrappers and onto personal machines.

#local-first

Show HN: DenchClaw Layers a Local CRM and Browser-Aware Workspace on Top of OpenClaw