Create ReCursor-Plugins Repository for Extensions and Integrations

[MasuRii]

Overview

Establish a separate repository for ReCursor plugins, extensions, and integrations with external coding agents, maintaining the modular architecture defined in architecture/overview.md.

Background

Per architecture/overview.md, ReCursor supports multiple integration paths:

Integration	Status	Use Case
Claude Code Hooks	✅ Supported	Event observation (one-way)
Agent SDK	✅ Supported	Parallel agent sessions
MCP	✅ Supported	Tool interoperability

A plugins repository would extend this to support additional coding agents and custom tooling.

Goals

• Keep core ReCursor mobile app (apps/mobile/) focused on UI and Bridge connection
• Enable modular integrations with other AI coding agents
• Maintain clear separation between core and community contributions
• Follow existing project structure conventions (per project-structure.md)

Scope

Based on research.md findings, potential integrations include:

Agent	Stars	Integration Approach
OpenCode	~122K	WebSocket bridge (similar pattern)
Aider	~42K	Git-native, CLI pass-through
Goose	~33K	MCP extensibility
Cline	~59K	Human-in-the-loop approvals

Package Types

Type	Description	Example
Agent Adapter	Connect ReCursor to different coding agents	recursor-opencode-adapter
Tool Extension	Additional tools for Agent SDK sessions	recursor-deploy-tool
UI Theme	OpenCode-style UI customizations	recursor-theme-dark
Notification Handler	Custom push notification patterns	recursor-slack-notifier

Naming Convention

All packages MUST use the recursor- prefix for discoverability:

recursor-<type>-<name>

Examples:
├── recursor-adapter-opencode
├── recursor-adapter-aider
├── recursor-tool-deploy
└── recursor-theme-midnight

Proposed Repository Structure

ReCursor-Plugins/
├── adapters/
│   ├── recursor-adapter-opencode/
│   ├── recursor-adapter-aider/
│   └── recursor-adapter-goose/
├── tools/
│   └── recursor-tool-deploy/
├── themes/
│   └── recursor-theme-midnight/
├── templates/
│   └── plugin-template/        # Starter kit for new plugins
└── README.md

Deliverables

• Define plugin/adapter interface contract (align with bridge-protocol.md)
• Create ReCursor-Plugins repository under RecursiveDev org
• Establish contribution guidelines (reference CONTRIBUTING.md)
• Create plugin template repository
• Document adapter patterns for multi-agent support (reference agent-sdk.md)

Principles

1. Modularity — Each adapter is independently versioned
2. Bridge Compatibility — All adapters work with ReCursor Bridge Server (per bridge-protocol.md)
3. OpenCode UI Consistency — Extensions must not break OpenCode-style UI patterns

Constraints

From AGENTS.md:

Claude Code Remote Control is first-party only. Do not claim we can join/mirror a user's Claude Code Remote Control session unless official docs explicitly provide it.

Plugins must only use supported integration mechanisms: Hooks, Agent SDK, MCP.

Related

• Architecture: architecture/overview.md
• Integration docs: integration/
• Bridge protocol: bridge-protocol.md
• Research: research.md

[MasuRii]

Research Update: Multi-Agent Extension Surfaces (2026-03-17)

This comment summarizes verified research on extension and integration surfaces for the ReCursor-Plugins repository.

---

ReCursor Current Contract

Per AGENTS.md and docs/README.md, ReCursor supports only documented integration mechanisms:

Mechanism	Direction	Use Case
Hooks	One-way (observation)	Event monitoring, notifications
Agent SDK	Bidirectional (parallel session)	Independent agent sessions controlled from mobile
MCP	Bidirectional	Tool interoperability

Critical Constraint:

Claude Code Remote Control is first-party only. Third-party clients cannot join/mirror Claude Code Remote Control sessions.

Citations:

• C:/Repository/ReCursor/AGENTS.md (Section 1)
• C:/Repository/ReCursor/docs/README.md
• C:/Repository/ReCursor/docs/research/claude-code-integration-feasibility-2026-03-17.md

---

Verified External Surfaces

Agent	MCP	Extensions	Hooks	Status	Source
Claude Code	✅	Plugins	✅ Type: command/prompt	Active	https://code.claude.com/docs/en/mcp
Gemini CLI	✅	✅ Full package system	✅	Active	https://github.com/google-gemini/gemini-cli/blob/main/docs/extensions/index.md
OpenCode	TBD	TBD	TBD	Active (not archived)	https://github.com/anomalyco/opencode

Correction: Previous research incorrectly stated OpenCode was archived. GitHub API confirms:

{"isArchived": false, "pushedAt": "2026-03-17T17:42:25Z"}

Gemini CLI Verified Features:

• MCP Servers: ~/.gemini/settings.json configuration
• Extensions: Packages prompts, MCP servers, custom commands, themes, hooks, sub-agents
• Hooks: Script-based interception at hook points

Claude Code MCP Docs:

• URL: https://code.claude.com/docs/en/mcp
• Title: "MCP - Claude Code Docs"
• Description: "Learn how to connect Claude Code to your tools with the Model Context Protocol."

Citations:

• C:/Repository/ReCursor/docs/research/verify-agents-web-claims-2026-03-17.md
• https://github.com/anomalyco/opencode (API: isArchived: false)
• https://github.com/google-gemini/gemini-cli/blob/main/README.md
• https://code.claude.com/docs/en/mcp

---

Phased Plan for ReCursor-Plugins Repository

Phase	Scope	Deliverables
1. Foundation	Plugin interface contract	Define adapter interface aligned with docs/bridge-protocol.md
2. Template	Plugin starter kit	Create plugin-template/ with contribution guidelines
3. Claude Adapters	Hooks bridge + Agent SDK wrapper	recursor-adapter-claude-hooks, recursor-adapter-claude-sdk
4. Gemini CLI	MCP + Extensions support	recursor-adapter-gemini-mcp
5. OpenCode	WebSocket bridge (UI parity reference)	recursor-adapter-opencode

Naming Convention: All packages use recursor-<type>-<name> prefix per issue spec.

---

Open Questions

Question	Status	Notes
pi coding agent surface	UNKNOWN	Not researched; no verified sources available
Crush/OpenCode relationship	UNVERIFIED	No official documentation found; omit from planning
OpenCode MCP support	TBD	Requires direct repository investigation

---

References

1. docs/integration/claude-code-hooks.md - Hooks integration guide
2. docs/integration/agent-sdk.md - Agent SDK integration guide
3. docs/research/multi-agent-extension-surface-2026-03-17.md - Full research report
4. docs/research/verify-agents-web-claims-2026-03-17.md - Verification evidence

[m13v]

We've integrated with multiple coding agent protocols in our macOS AI agent (Fazm) and the plugin architecture decision is important. Some thoughts:

For the Claude Code Hooks integration (one-way observation), the key events to capture are: tool_call (what tool was invoked), tool_result (what came back), and conversation_turn (what the agent said). These three give you full visibility into what the agent is doing without interfering with its execution.

For Agent SDK integration (parallel sessions), the main challenge is state isolation. Each agent session needs its own working directory, environment variables, and tool permissions. We use git worktrees to give each agent an isolated copy of the repo. The plugin should manage worktree creation/cleanup lifecycle.

For MCP tool interoperability, define your plugin's tools using the MCP schema format (name, description, inputSchema as JSON Schema). This lets any MCP-compatible agent discover and use your plugin's tools without custom integration code.

Plugin architecture suggestion: use a simple manifest file per plugin (plugin.json) that declares: supported integration types, required permissions, tool definitions, and event subscriptions. The core app loads plugins by scanning a directory and validating manifests. Keep plugins as separate npm packages or directories so they can be versioned independently.

One practical consideration: different coding agents have very different context window sizes and tool calling capabilities. Plugins should declare minimum requirements so the core app can warn if an agent doesn't meet them.

[m13v]

Our MCP server implementation for macOS automation is open source: https://github.com/mediar-ai/mcp-server-macos-use/blob/main/Sources/MCPServer/main.swift

Shows tool definitions in MCP format, accessibility API integration, and the plugin-style architecture for agent tool interoperability.