What AgentDock Does and What You Can Build on It
A practical look at AgentDock: what its desktop-agent runtime implements today, where the boundaries are, and five focused products you could build around it.
“Agent dock” is not an established software category with one agreed specification. I use the term for the layer where agents are launched, supervised, interrupted, and connected to the files and tools needed for a piece of work.
The dock is not the finished product. It is the runtime underneath it.
A useful dock should give the user somewhere to see what an agent is doing, inspect evidence, answer questions, pause before consequential actions, and keep a record of the result. AgentDock provides runtime primitives for that shape, but the exact interactions and evidence depend on the negotiated transport and the downstream workflow. The actual product still needs a specific user, policy, and definition of done.
That is the role I built AgentDock to play.
What AgentDock is today
AgentDock is open-source, fork-first boilerplate for building desktop products around Claude and
Codex agents. It supports a pinned Claude Agent SDK transport on eligible Windows setups, a
compatibility path through an installed claude CLI, and Codex through an installed codex CLI
using either its app-server transport or codex exec.
It combines:
- an Electron desktop shell
- a React reference interface
- a local Fastify daemon
- provider adapters for Claude and Codex
- typed communication between the desktop and daemon
- normalized session events
- workspace trust, interaction routing, approval audit, and v2 history infrastructure
- a Windows packaging base
The included interface is deliberately generic. It exists so a developer can run the complete path and understand how the pieces fit together. A real fork is expected to replace the workflow, copy, visual identity, and much of the interface.
The runtime path looks like this:
React renderer
-> typed Electron IPC
-> Electron main
-> AgentDock client
-> authenticated loopback daemon
-> Claude Agent SDK, installed claude CLI, or installed codex CLI (app-server / exec)
The React renderer does not call the daemon directly. Electron main owns the authenticated
connection, and the renderer receives a fixed set of operations through the preload bridge. The
daemon listens on 127.0.0.1, generates a new bearer token at startup, requires it on every route
except the minimal GET /health, and rejects browser-originated requests.
This boundary matters because “it only runs on localhost” is not enough protection. A normal webpage can attempt to contact services on localhost. AgentDock keeps the token out of browser-facing code and does not expose a generic request tunnel from the renderer.
AgentDock has no credential UI or hosted product database. It does not persist provider credentials
or proxy them through its HTTP API. The Claude SDK child receives an allowlisted credential
environment for the selected auth source. The installed claude and codex CLIs use their own
runtimes, which remain responsible for login.
What the runtime already provides
The protocol-v2 path includes a provider-neutral session lifecycle, streamed events, workspace trust, interaction routing, durable normalized session history, interactive-approval audit records, and guarded concurrency.
That sentence needs an important qualification: capabilities are negotiated for the selected provider, transport, version, platform, authentication mode, workspace trust, and runtime evidence.
AgentDock does not pretend every provider supports every operation. Native resume, fork, interactive questions, approvals, and other capabilities can differ between the Claude SDK, Claude CLI, Codex app-server, and the one-shot CLI compatibility paths. A downstream product should verify the exact transport it plans to support instead of branching only on the provider name.
Concurrency is guarded rather than unlimited. Mutation-capable sessions take an exclusive workspace lease, while shared reads of a dirty workspace require explicit opt-in.
Some supporting surfaces are also already implemented:
- preview, creation, listing, and guarded cleanup of AgentDock-owned Git worktrees
- provider detection and capability reporting
- authenticated HTTP and SSE clients for trusted Node or Electron code
- local workspace trust and audit state
- provider-fixture tests that do not require live paid sessions
- Windows NSIS packaging
Other surfaces exist only in a narrower form:
- MCP has normalized control-plane routes, but current production adapters expose only inspection and the configuration actions their providers support. Live catalogs, OAuth, and direct tool invocation are unavailable.
- Extension discovery can inspect supported skills, plugins, hooks, commands, and agents, but it is read-only. Management and invocation are unavailable.
- Subagent graph storage and routes exist, but production provider events do not currently populate that graph.
- File staging and structured-output validation exist, but session creation does not yet dispatch attachments or output schemas into provider execution.
The product shape that fits AgentDock
The product shape AgentDock supports best is not a generic chat window. It is a bounded workbench.
A user brings in one case: a repository, failed build, document set, incident, transaction, or review request. The product defines a bounded scope and turns the work into a visible sequence. AgentDock’s workspace-trust gate records consent and controls admission; it is not proof that an agent is confined to the selected filesystem or network scope.
- Accept a bounded input.
- Show the proposed approach and requested capabilities.
- Display runtime progress and product-collected source evidence.
- Pause for questions or actions when the selected transport supports those interactions.
- Apply the product’s policy and human gates before consequential work.
- Let downstream verification rerun checks against the result.
- Have the fork produce its domain artifact: a diff, brief, matrix, or review packet.
- Use durable v2 history and separate approval records to explain what happened later.
Not every item in that sequence is a ready-made AgentDock screen or API call. It is a downstream product pattern built from the runtime’s sessions, events, trust, interaction, and history primitives.
The important shift is from “ask an agent anything” to “complete this repeated job, inside this scope, with this evidence and approval policy.”
From the larger product concept directory, here are five examples I think fit that shape particularly well. They are product hypotheses, not claims of market validation or product-market fit.
1. Dependency Upgrade Studio
Dependency upgrades are repetitive, repository-based, and easier to verify than many other agent tasks.
A narrow first product could support one package ecosystem and one verified provider transport. It would:
- inventory outdated dependencies
- group a small upgrade batch
- explain compatibility risks
- make the changes in a separate AgentDock-owned Git worktree
- run the repository’s existing checks
- produce a diff and verification report
- wait for a maintainer before integration
AgentDock already supplies useful runtime pieces: trusted workspace sessions, streamed progress, guarded worktree operations, interaction handling where negotiated, and durable v2 history.
The fork still needs the actual product logic: package-manager rules, upgrade policy, risk classification, test selection, failure recovery, and integration with the team’s pull-request workflow.
What would make this useful is not simply “we can ask an agent to update packages.” It is the upgrade policy, evidence quality, supported ecosystems, and reliability of the verification loop.
2. CI Failure Investigator
A failed CI job usually starts with scattered evidence: logs, environment information, recent changes, and a repository that may or may not reproduce the problem locally.
A focused investigator could collect one failed job, build a timeline, reproduce the failure, rank likely causes, propose a bounded fix, and attach proof from a clean rerun.
AgentDock can supervise the local session and keep the agent’s progress visible. Its provider-neutral event model supplies a common baseline, but a real product still needs capability-aware interface variants for transport-specific behavior.
The CI connection is downstream work. AgentDock does not ship a GitHub Actions, GitLab, or observability integration, and its current MCP implementation is not a general live-tool invocation layer. A first version could avoid that dependency by accepting an exported log and a local checkout. A later version could add one carefully scoped CI connector.
The approval boundary should remain explicit: reproducing a failure is one thing; pushing code, rerunning expensive infrastructure, or changing a deployment is another.
3. Release Readiness Gate
Release work is often a checklist spread across scripts, documentation, security notes, packaging output, and human memory.
A release-readiness product could turn that into one versioned case:
- identify the candidate revision
- run the required checks
- compare documentation with current behavior
- inspect packaging artifacts
- collect known exceptions
- produce a go/no-go packet
- require a human release decision
AgentDock provides the local runtime, durable normalized v2 session history, and a separate interactive-approval audit. That audit is not a tamper-evident, compliance-grade, or complete action-provenance ledger. The downstream product must define the checklist, understand the project’s release policy, invoke only the supported tools for its selected transport, and render failures in a useful domain-specific interface.
This is a good example of why the UI should not remain a generic composer. The useful screen is a release matrix with evidence, owners, exceptions, and an approval state.
4. Agent Eval and Regression Lab
Provider-neutral sessions create an interesting base for comparing agent behavior, but AgentDock is not an evaluation platform today.
A dedicated fork could run a fixed repository fixture through selected Claude and Codex transports, normalize the observable outcomes, and record whether a change is safe to promote.
A credible first version would need:
- versioned fixtures
- exact provider and transport metadata
- deterministic checks where possible
- bounded output comparison
- cost and latency capture
- a human promotion decision
AgentDock already normalizes session events and preserves compatibility metadata and durable v2 history. The evaluation cases, scorers, repeatability controls, reporting, and statistical interpretation are all downstream responsibilities.
That distinction matters. Running the same prompt twice is not automatically an evaluation, and one successful fixture is not a provider-parity guarantee.
5. Evidence-to-Brief Studio
Not every useful agent product needs to modify code.
A research or operations team could select a controlled project folder and turn it into a cited decision memo with an evidence appendix. The product could show which files support each claim, separate observed facts from inference, ask for missing context, and export a review packet.
The current checkout can already run an agent against a trusted workspace and stream its progress. However, AgentDock’s attachment staging is not wired into session execution. A first implementation would need to treat the selected folder as the workspace or add its own ingestion path. Citation extraction, document parsing, rights handling, and polished export are also product-layer work.
This pattern can extend into proposals, procurement, support escalation, compliance evidence, or research publishing. The more regulated the domain becomes, the more important it is that the agent prepares evidence for a qualified reviewer instead of making the final decision.
What AgentDock does not give the fork
AgentDock removes part of the infrastructure burden. It does not remove product development.
A downstream team still owns:
- the user and repeated problem
- the domain-specific interface
- accounts and cloud synchronization
- hosted storage and collaboration
- integrations and connector permissions
- evaluation criteria and fixtures
- retention and privacy policy
- billing, distribution, signing, and support
- professional review for regulated decisions
The repository is not a hosted backend or a collection of public npm packages. Its internal client and shared packages are private workspace packages intended to stay together inside a fork.
Windows is the only verified packaging target today, and the generated installer is unsigned. macOS and Linux application distribution remain downstream work.
A local daemon also does not make a product offline. Prompts, selected file contents, and tool results can still reach the chosen provider under that provider’s terms and data policy. Anyone building on AgentDock still needs to review data flow, retention, provider configuration, and the permissions of every connected tool. Durable normalized v2 history is stored locally in plaintext under the repository’s bounded retention rules.
When I would choose a different base
I would not start with AgentDock if I needed:
- a ready-made consumer chat application
- a browser-only or hosted multi-user product
- a fully offline local-model runtime
- verified distribution across desktop platforms
I would also avoid using it as the sole safety mechanism for autonomous legal, medical, financial, employment, security, or compliance decisions. AgentDock can help build a review workflow. It does not provide the domain evaluation, governance, or compliance program.
How I would choose the first product
Before building a full fork, I would score the workflow against a few practical questions:
- Does the same job happen repeatedly for a clearly identified user?
- Does the work already live in files, repositories, or desktop-accessible tools?
- Is there a bounded case and an observable done state?
- Can the result be verified instead of merely sounding plausible?
- Is there a natural approval point before an expensive or irreversible action?
- Can version one use one input source, one action integration, and one artifact type?
- Are past cases available for fixtures and regression tests?
- Does the product add workflow knowledge or policy beyond the model itself?
The best first version is usually:
draft
-> show evidence
-> human review
-> approved action
-> verification
More autonomy should come after measured reliability, not before it.
The actual opportunity
The valuable part is the reusable boundary around the agent: trusted workspace selection, provider negotiation, observable sessions, narrow desktop IPC, interaction handling where negotiated, durable v2 history, and room for a downstream approval policy.
That still leaves the difficult product questions open. Who has the problem? Which case enters the system? What evidence is enough? What can the agent change? What always requires approval? What artifact proves the work is complete?
AgentDock gives a fork somewhere solid to start answering those questions. It does not answer them on the product’s behalf.