dear-claude

In one line. dear-claude watches your existing planning tools for the phrase "Dear Claude" and automatically spawns a local Claude Code instance to do the work, so your tasks become pull requests without your code ever leaving your machine.

Every team already has a place where work lives: Linear, Jira, GitHub Issues, Notion, Obsidian. And for the last year, that work has been getting done partly by AI, but always with a hitch. You copy a ticket description, paste it into a chat interface, receive a code block, paste it back into your editor, review it, and commit it yourself. The seam between planning and execution stays manual. dear-claude closes that seam: write a task the way you always have, add "Dear Claude" anywhere in it, and a Claude Code instance spins up locally to handle it end to end.

Figure 1. Left: a developer copies a ticket description into a chat interface, receives code, and pastes it back manually. Right: the same developer writes the ticket normally; dear-claude picks it up, executes locally, and posts results back to the originating platform.

Why this matters

• For developer teams: the gap between "task written" and "PR open" is still a human-hours gap; turning a ticket into a PR currently requires context-switching out of your planning tool and into an editor, then back again to update the ticket.
• For teams with data residency requirements: every AI coding SaaS sends your source code to a third-party inference API; dear-claude executes inside a local git worktree, so code never leaves your machine, which is the only architecture that can satisfy a "no external code processing" policy without bureaucratic exceptions.
• For teams already using MCP-aware tooling: Model Context Protocol (Anthropic, Nov 2024; donated to the Linux Foundation's Agentic AI Foundation, Dec 2025) is becoming the standard interface between AI models and external tools; dear-claude is built on MCP, which means it participates in the same ecosystem as every other agent-aware tool your stack adopts.

🧭 If you only read this far: dear-claude turns the planning tools you already use into a local AI execution environment, with no code leaving your infrastructure.

Terms in 30 seconds

Domain engineers: skip ahead, this is orientation for everyone else.

• MCP (Model Context Protocol): the open protocol that lets an AI model talk to external tools and data sources (Anthropic, Nov 2024; donated to the Linux Foundation's Agentic AI Foundation, Dec 2025). (modelcontextprotocol.io)
• Claude Agent SDK: Anthropic's SDK for spawning and coordinating Claude Code instances programmatically, used here to launch local agents in response to webhook events.
• Claude Code: Anthropic's terminal-based AI coding agent; dear-claude uses it as its local execution engine.
• Git worktree: a built-in Git feature that checks out a branch in a separate directory without affecting your working tree; dear-claude uses one per task so parallel agents do not conflict.
• Tailscale Funnel: a Tailscale feature that exposes a port on your local machine via a stable public HTTPS URL, used here to receive webhooks from external platforms without standing up cloud infrastructure.
• Webhook: an HTTP callback a platform sends to a URL you register whenever something happens (issue created, comment posted, etc.).

Note on supply-chain regulation: dear-claude is agentic developer tooling, not a shipped software artifact, so EU CRA / SBOM mandates do not apply directly. The privacy property (local execution) is relevant for internal data-handling policies, not for regulatory compliance in the CRA sense.

The problem, for engineers who don't live in this space

Imagine a well-run office where every task is written on a whiteboard in plain language. Execution still requires someone to read the board, walk to their desk, do the work, and walk back to update the board. The whiteboard and the execution environment are separate rooms. That is how AI-assisted development works today for most teams: the planning tool (Linear, Jira, GitHub) and the AI coding agent (Claude Code, Cursor, Copilot) are separate rooms with a human acting as the courier between them.

Here is the concrete version. A team uses Linear to track bugs. An engineer writes: "The user profile API returns 500 when avatar_url is null, fix it and add a test." Today that engineer opens a terminal, pastes the ticket text into a chat interface, receives a code suggestion, opens their editor, applies it, writes the test, runs CI, opens a PR, and goes back to Linear to update the ticket status. Six manual steps across three different tools. Multiply by twenty engineers and fifty tickets a week.

Figure 2. The current flow: a ticket exists in Linear/Jira/GitHub, a human copies context into a separate AI interface, receives code, applies it manually, then returns to the planning tool to close the loop. The human is the integration layer between planning and execution.

Why this is genuinely hard. The planning tools (Linear, Jira, GitHub, Notion, Obsidian) each have different event models, webhooks for some, OAuth for others, filesystem watching for Obsidian, and the AI execution layer needs to be locally hosted to preserve code privacy while still receiving events from cloud platforms. Bridging those two worlds without standing up persistent cloud infrastructure is the engineering problem.

What exists today (and the gap)

No existing tool combines webhook-driven detection across multiple PM platforms, local Claude Code execution via the Agent SDK, git worktree isolation for parallel tasks, and result posting back to the originating platform, all in a single self-hosted MCP server. The empty column is local execution at scale across heterogeneous planning tools.

How it works

dear-claude is a single MCP server that sits between your planning tools and your local machine. When a trigger phrase is detected, it spawns a Claude Code instance in an isolated git worktree, runs the task, and posts results back. It has four parts:

• Webhook receiver: a Tailscale Funnel HTTPS endpoint that accepts platform events from GitHub, Linear, Jira, GitLab, and Notion; plus a filesystem watcher for Obsidian.
• Context parser: extracts the task description, linked comments, and relevant code context from the raw event payload.
• Agent spawner: uses the Claude Agent SDK to launch a Claude Code instance with the parsed context, isolated in a dedicated git worktree.
• Result poster: sends the agent's output (code changes, PR links, summaries) back to the originating platform as comments, sub-task updates, status transitions, or file appends.

Figure 3. Event arrives at the Tailscale Funnel endpoint (or Obsidian filesystem watcher), the context parser extracts task details, the Agent SDK spawns a local Claude Code instance in a git worktree, and results flow back to the originating platform. Your code never leaves the machine boundary (dashed).

Webhook receiver and Tailscale Funnel

Rather than requiring users to expose a port to the open internet or pay for cloud relay infrastructure, dear-claude uses Tailscale Funnel, a feature of Tailscale's network that creates a stable public HTTPS URL tunneled to a local port. This is the only externally-visible surface; everything behind it runs locally. Obsidian, which has no webhook API, is handled separately via filesystem watching that detects changes to .md files and applies the same trigger detection.

Context parser and trigger detection

The trigger phrase is "Dear Claude" appearing anywhere in an issue description, PR body, or comment. When detected, the parser assembles a structured prompt: the task description, recent comments for context, and any code snippets linked in the ticket. Platform-specific context is normalized before being handed to the agent.

Agent spawner and git worktrees

The Agent SDK launches a Claude Code instance with the assembled context. Each task gets its own git worktree, a separate checked-out directory on the same repo, so multiple instances can run in parallel without conflicting. Instances persist for 7 days, support multi-turn conversations (follow-up comments in the originating platform extend the same instance), and can spawn child instances for parallel sub-tasks, forming a parent-child hierarchy.

Result poster

When the agent completes, dear-claude posts results back through the originating platform's API: a comment on the GitHub issue with the PR link, a Linear sub-task marked done, a Jira status transition, a GitLab merge-request comment, a Notion page update, or an appended section in an Obsidian file.

The decisions that actually mattered

Tailscale Funnel vs. a hosted relay

The fork. To receive webhooks from cloud platforms, something has to be publicly addressable. The options were: host a small cloud relay (a persistent server that forwards events to a local agent), or use Tailscale Funnel to expose the local server directly. Chosen. Tailscale Funnel. Trade-off accepted. Users must have Tailscale installed and Funnel enabled, which is an additional prerequisite, but it means dear-claude has no persistent cloud component and no infrastructure to maintain or pay for. The self-hosted constraint is real: if your machine sleeps, events queue or drop.

One MCP server vs. per-platform adapters

The fork. Build a separate adapter per platform, each installable independently, or unify everything behind one MCP server that Claude Code installs with a single command. Chosen. A single MCP server. Trade-off accepted. The server carries connectors for all six platforms, which means you install code for platforms you may not use, but the single-command install (claude mcp add dear-claude -- bunx dear-claude start --mcp) is a meaningful DX win, and the MCP protocol handles capability negotiation so unused connectors are inert.

Why this is new, and why it's significant

What's novel. dear-claude is, to my knowledge, the first single self-hosted MCP server that combines webhook-driven trigger detection across six heterogeneous PM platforms with local Claude Code execution via the Agent SDK inside git worktrees, with bidirectional result posting. The combination, not any individual piece, is the contribution. GitHub bots run in the cloud. Linear automations don't write code. Hosted AI coding SaaS sends your code to their inference infrastructure. None of them do all of this locally.

Why it's significant to the field. The Model Context Protocol (MCP) and the Claude Agent SDK represent an emerging infrastructure layer for agentic developer tooling, one where the interesting design questions are about where agents run and how they receive context, not just what model powers them. dear-claude demonstrates a specific and underexplored point in that design space: the PM tool as the agent's primary interface, with execution staying local. MCP's move to the Linux Foundation's Agentic AI Foundation (Dec 2025) signals that the protocol is becoming infrastructure, not a vendor feature. Tools that show what MCP-native, locally-executed agentic workflows look like in practice contribute to the emerging understanding of that infrastructure layer.

Standards and ecosystem alignment. This work implements and aligns with:

• MCP (Model Context Protocol): dear-claude is installed and communicates as a standards-compliant MCP server, using the claude mcp add installation path.
• Claude Agent SDK: instance spawning, multi-turn conversations, and parent-child hierarchies use the Agent SDK's published interfaces.
• Git worktrees: parallel execution uses the native git worktree mechanism (Git 2.5+) rather than cloning, keeping disk usage and state management clean.

📌 Honest scope. dear-claude is self-hosted: your machine must be running and Tailscale Funnel must be active for events to reach it. Notion's webhook support is limited (internal tokens or OAuth; not all event types are reliably delivered), so Notion integration is best-effort. This is not a hosted SaaS and has not been independently adopted at scale. The novelty claim is about the combination of local execution, multi-platform coverage, and MCP-native installation, not about any individual underlying primitive.

See it run

# Install the MCP server into Claude Code
claude mcp add dear-claude -- bunx dear-claude start --mcp

# Set credentials for your platform of choice (GitHub shown here)
export GITHUB_WEBHOOK_SECRET=your_secret
export GITHUB_TOKEN=your_pat

Then, in any GitHub issue:

Hey team, this endpoint is returning 500 when avatar_url is null.

Dear Claude, please fix the null check in src/api/users.ts and add a regression test.

dear-claude: trigger detected in issue #412
→ spawning agent in worktree: .git/worktrees/task-412
→ context: 3 comments, 1 linked file
→ agent running...  # ← local Claude Code instance, your machine
→ PR opened: feat/fix-avatar-null-check (#413)
→ posted comment to issue #412  # ← results back to GitHub

🔬 Go deeper. The six platform connectors and the Agent SDK spawning logic live in src/platforms/ and src/agent/ in the repository. Check the README for Tailscale Funnel setup and the per-platform environment variable reference.

What's next

Near-term: more robust Notion webhook support as Notion's API evolves, and additional PM platforms (Asana, Height). dear-claude is the second piece in in8's agentic-developer-tooling line, alongside better-call-claude. The shared thesis across the line is that your existing interfaces, phone calls, messages, planning boards, should be sufficient to direct a local agent, without requiring a new interface or sending your code to a third party. The planning tools you already use should just work.

Appendix / references

• Repository: github.com/sns45/dear-claude
• Related in this series: better-call-claude · tickettok
• Standards referenced: MCP (modelcontextprotocol.io) · Claude Agent SDK · Tailscale Funnel · Git worktrees (Git 2.5+)
• Discussion / feedback: github.com/sns45/dear-claude/issues