CodeMie AI Coding Assistant

The Plugin System allows you to extend CodeMie Code by bundling reusable packages of skills, commands, agents, hooks, and MCP servers.

Key features include:

• Bundling: Package multiple components into a single distributable unit.
• Namespacing: All components are automatically prefixed with plugin-name: (e.g., security-tools:code-review) to prevent naming conflicts.
• Distribution: Plugins can be shared via directories, git repositories, or local paths.
• Management: Use the codemie plugin CLI to install, uninstall, enable, or disable plugins.
• Automatic Discovery: Plugins are automatically detected from project, user, and CLI-specified locations.

The CodeMie Hooks system allows you to extend agent execution by running custom shell commands or LLM-based prompts at specific lifecycle points. Hooks can be used to inject context, block or modify tool usage, track activity, or enforce security policies. Hooks are configured within your profile in the ~/.codemie/codemie-cli.config.json file.

{
  "version": 2,
  "activeProfile": "default",
  "profiles": {
    "default": {
      "hooks": {
        "PreToolUse": [
          {
            "matcher": "Bash|Write",
            "hooks": [
              {
                "type": "command",
                "command": "/path/to/pre-tool-hook.sh",
                "timeout": 60000
              }
            ]
          }
        ]
      }
    }
  }
}

When working with the Copilot CLI managed agent, note the following naming conventions used for command boundaries and internal identification:

• User-facing alias: copilot (used at command boundaries).
• Launcher/Help commands: Render as codemie-copilot or codemie install copilot.
• Internal key: copilot-cli (used in interfaces and conversation folder expectations).
• Client identity: codemie-copilot.

When implementing or modifying session ownership logic, adhere to these technical constraints:

• Resolution Order: Ownership resolution must be index-first (using correlation JSON + sidecar marker). Only fall back to a bounded transcript scan for legacy sessions. Never perform a full-file read for ownership checks.
• Safety: Wrap every filesystem read in a non-fatal try/catch. If a read fails, the system must fail-closed for ownership determination (i.e., treat the session as 'external/not owned').
• Performance: Ownership index results may be cached for the duration of the process lifetime, as analytics CLI runs are typically short-lived.
• Marker Storage: Ownership markers should be stored in a sidecar file rather than appended to the live transcript to avoid appendFileSync race conditions.

The CodeMie CLI identifies repositories by normalizing the Git origin remote URL into a stable <org>/<repo> format. This ensures metrics contain privacy-safe and consistent identifiers.

Normalization Rules:

• Removes protocols (e.g., https://, git@).
• Removes hostnames (e.g., github.com).
• Removes embedded credentials or tokens.
• Removes the .git suffix.

Examples:

• git@gitbud.epam.com:epm-cdme/codemie.git $\rightarrow$ epm-cdme/codemie
• git@github.com:codemie-ai/codemie-code.git $\rightarrow$ codemie-ai/codemie-code
• https://user:token@github.com/org/repo.git $\rightarrow$ org/repo

/* Logic implemented in src/utils/processes.ts */
// Input: git@github.com:codemie-ai/codemie-code.git
// Output: codemie-ai/codemie-code

The proxy operates through four distinct layers:

1. Layer 1: Entry Point (CodeMieProxy): Manages the HTTP server lifecycle, port binding, and top-level error handling.
2. Layer 2: Plugin Management (PluginRegistry): Handles plugin registration, priority-based sorting, and lifecycle management (enable/disable).
3. Layer 3: Request Handling: Orchestrates context building and hook execution (onRequest, onResponseHeaders, etc.) while managing errors via plugin hooks.
4. Layer 4: HTTP Forwarding (ProxyHTTPClient): Manages upstream connections, SSL/TLS, and ensures true HTTP streaming without buffering.

Plugin discovery in this system relies on explicit registration at composition entrypoints. If a plugin is not imported into the correct entrypoint, registry lookups will fail with unsupported or not-found errors rather than falling back to a default plugin.

Key Entrypoints for Registration:

• AgentRegistry: For adding to the lazy built-in list.
• src/providers/index.ts: For provider-specific plugins.
• src/frameworks/plugins/index.ts: For framework-specific plugins.

Note that importing these composition entrypoints has side effects and should be performed at a startup boundary or an explicit integration setup point.

The installation engine uses two primary enums to track the lifecycle and results of installation tasks.

StepStatus

Represents the current state of an individual Step:

• .pending: Waiting to be executed.
• .active: Currently running.
• .complete: Successfully finished.
• .warning(String): Finished, but with non-fatal issues.
• .error(String): Failed to execute.
• .skipped: Not executed due to conditions.

RunOutcome

Represents the final result of the entire installation process:

• .success: All steps completed successfully.
• .completedWithWarnings([String]): Installation finished, but some warnings were issued.
• .failed(stepId: String, message: String, recommendation: String): Installation stopped due to a critical error.
• .aborted: Installation was manually cancelled by the user.