agentsmesh import

Import an existing tool’s native config into the canonical .agentsmesh/ directory. The import is lossless — internal file references, cross-skill links, and tool-specific metadata are all preserved.

Usage

agentsmesh import --from <target>

agentsmesh import --global --from claude-code

Flags

Flag	Description
`--from <target>`	Source tool ID to import from. Required.
`--global`	Import from user-level tool paths into `~/.agentsmesh/`. See the global-mode sections below for target-specific paths and current importer caveats.

Supported targets

The table below lists every builtin target’s project-scope import root. With --global, AgentsMesh uses the user-level paths documented in the global-mode sections below. This table is generated from the target catalog — see the support matrix for full feature coverage per tool.

Target ID	Tool	Reads from
`aider`	Aider	`CONVENTIONS.md`
`amazon-q`	Amazon Q Developer	`.amazonq/rules`
`amp`	Amp	`AGENTS.md`
`antigravity`	Antigravity	`.agents/rules`
`augment-code`	Augment Code	`.augment/rules`
`claude-code`	Claude Code	`CLAUDE.md`
`cline`	Cline	`AGENTS.md`
`codebuff`	Codebuff	`AGENTS.md`
`codex-cli`	Codex CLI	`AGENTS.md`
`continue`	Continue	`.continue/rules`
`copilot`	GitHub Copilot	`.github/copilot-instructions.md`
`crush`	Crush	`CRUSH.md`
`cursor`	Cursor	`.cursor/rules/general.mdc`
`deepagents-cli`	Deep Agents CLI	`.deepagents/AGENTS.md`
`factory-droid`	Factory Droid	`AGENTS.md`
`gemini-cli`	Gemini CLI	`.gemini/rules`
`goose`	Goose	`.goosehints`
`jules`	Jules	`AGENTS.md`
`junie`	Junie	`.junie/rules`
`kilo-code`	Kilo Code	`AGENTS.md`
`kimi-code`	Kimi Code CLI	`AGENTS.md`
`kiro`	Kiro	`AGENTS.md`
`opencode`	OpenCode	`AGENTS.md`
`openhands`	OpenHands	`AGENTS.md`
`pi-agent`	Pi Agent	`AGENTS.md`
`qwen-code`	Qwen Code	`QWEN.md`
`replit-agent`	Replit Agent	`replit.md`
`roo-code`	Roo Code	`.roo/rules/00-root.md`
`rovodev`	Rovo Dev	`AGENTS.md`
`trae`	Trae	`.trae/rules/project_rules.md`
`warp`	Warp	`WARP.md`
`windsurf`	Windsurf	`AGENTS.md`
`zed`	Zed	`.rules`

Examples

# Import Claude Code configuration
agentsmesh import --from claude-code

# Import Claude Code global configuration from ~/.claude/ into ~/.agentsmesh/
agentsmesh import --global --from claude-code

# Import Cursor rules and settings
agentsmesh import --from cursor

Any target ID from the table above is valid for --from. Run agentsmesh init first if you’re unsure which tools have configs in the current project — it auto-detects every builtin target.

What import maps

The same canonical structure under .agentsmesh/ is produced regardless of which target you import from:

Source feature	Canonical destination
Root rule + per-file rules	`.agentsmesh/rules/_root.md`, `.agentsmesh/rules/*.md`
Commands / prompts / workflows	`.agentsmesh/commands/*.md`
Agents / subagents / droids	`.agentsmesh/agents/*.md`
Skills / SKILL bundles	`.agentsmesh/skills/<name>/SKILL.md` (+ supporting files)
MCP servers	`.agentsmesh/mcp.json`
Hooks	`.agentsmesh/hooks.yaml`
Permissions	`.agentsmesh/permissions.yaml`
Ignore patterns	`.agentsmesh/ignore`

Each target’s native file paths and feature support are listed in the supported tools matrix. Embedded features (e.g., Codex CLI commands projected as skills) are restored to their original canonical format on import — not the projected wrapper.

Global-mode caveats

A handful of targets have global-mode importer behavior worth noting. For every target not listed here, --global simply reads from the documented user-level paths and writes to ~/.agentsmesh/.

Antigravity

Project-only paths such as .agents/workflows/ are not scanned in global mode.

Cline

agentsmesh generate --global --targets cline writes rules to ~/.cline/data/settings/rules/, workflows to ~/Documents/Cline/Workflows/, hooks to ~/.cline/hooks/, and skills to ~/.cline/data/settings/skills/ — the importer reads back from these same documented global directories. MCP, ignore, and agents have no documented global surface (per docs.cline.bot/cli/cli-reference) and are project-only; they are neither generated nor imported at global scope.

Windsurf

agentsmesh generate --global --targets windsurf writes native user-level files under ~/.codeium/windsurf/, but the current importer reads Windsurf’s project-style paths under $HOME (~/.windsurfrules or ~/AGENTS.md, ~/.windsurf/, ~/.windsurfignore or ~/.codeiumignore).

Codex CLI

~/.codex/AGENTS.override.md is preferred over ~/.codex/AGENTS.md when both exist. Global import does not recurse nested AGENTS.md files under $HOME.

Cursor

Global import reads ~/.cursor/rules/*.mdc first, then falls back to legacy ~/.agentsmesh-exports/cursor/user-rules.md or ~/.cursor/AGENTS.md, and reads MCP, hooks, ignore, skills, agents, and commands from ~/.cursor/.

Reference rewriting

During import, AgentsMesh rewrites internal file references:

.claude/skills/api-gen/template.hbs → .agentsmesh/skills/api-gen/template.hbs
Tool-relative paths → canonical paths

This keeps cross-references valid after import.

Importing more than one tool

Most canonical paths are last-import-wins: if two tools each define a command named ship, the second import replaces the first, because both describe the same entity. agentsmesh init --yes is different: it imports all tools in one run, so it keeps both texts and saves the later tool’s version as ship-<tool>.md. See Auto-detection.

Permissions, ignore patterns and MCP servers are different: each is a list of separate entries, not one entity. A second import adds its entries to what is already in .agentsmesh/permissions.yaml, .agentsmesh/ignore and .agentsmesh/mcp.json, and keeps the entries the first tool brought in. So a Claude Code deny rule survives a later Cursor import. When two tools define an MCP server with the same name, the later import wins for that server. Import never removes an entry from these files; to drop one, edit the canonical file and run agentsmesh generate.

.agentsmesh/rules/_root.md is also an exception. It is the single slot every tool’s root instruction collapses into, so CLAUDE.md and an always-apply Cursor rule are different rules that merely share a destination. Importing the second one appends it to the first instead of replacing it, and the CLI says the root rule was merged:

agentsmesh import --from claude-code
agentsmesh import --from cursor
# Root rule merged into .agentsmesh/rules/_root.md — it already held another
# tool's rules, so both are kept. Review and edit it if they overlap.

agentsmesh init reports the same thing when it auto-imports several detected tools at once. Open .agentsmesh/rules/_root.md afterwards and remove anything the two tools said twice in different words — the merge preserves content, it does not reconcile it.

Import idempotency

Running import twice on the same source is safe. Existing canonical files are merged — no duplicates are created. For the root rule specifically, re-importing unchanged content changes nothing, and re-importing a source that gained lines upstream replaces the shorter body rather than appending a near-duplicate beside it.

Post-import: MCP server entry

After importing from a tool that manages MCP servers (e.g. claude-code, cursor, gemini-cli), the AgentsMesh self-serve MCP server entry is seeded into .agentsmesh/mcp.json if it is not already present. This ensures the MCP Server entry survives import round-trips and is always available after generation.

Seeding preserves the rest of the file: every other server, every per-server field AgentsMesh does not model (cwd, disabled, timeout), and every top-level key stay exactly as written. A file that cannot be rewritten safely — invalid JSON, or JSON with comments a rewrite would discard — is left untouched, and a warning names the reason so you can add the entry by hand.