DEV Community

Abhay Rao
Abhay Rao

Posted on

Migrating Codex and Claude Code Plugins to IBM Bob: A Practical Guide

#ai #ibmbob #claude #openai

Credit: This article is inspired by and paraphrases research and examples shared by Markus Eisele. The original work explores how existing Codex and Claude Code plugin ecosystems can be adapted to IBM Bob's project-based architecture.

As developer-focused AI tooling continues to evolve, many teams are starting to evaluate how existing AI workflows can be reused across platforms. If you've invested in Codex plugins or Claude Code extensions, the good news is that much of the logic can be migrated to IBM Bob.

The challenge is that IBM Bob follows a different philosophy.

While Codex and Claude Code package capabilities inside plugin manifests, IBM Bob organizes functionality through project-level configuration inside the .bob/ directory. The migration is less about copying files and more about mapping capabilities to Bob's native concepts.

The Core Difference

Both Codex and Claude Code use plugin containers.

Examples include:

.codex-plugin/plugin.json
.claude-plugin/plugin.json
Enter fullscreen mode Exit fullscreen mode

IBM Bob doesn't currently provide a direct equivalent.

Instead, capabilities are distributed across various project-level components:

.bob/
├── skills/
├── commands/
├── agents/
├── hooks/
├── mcp.json
└── settings.json
Enter fullscreen mode Exit fullscreen mode

Rather than migrating a plugin as a single unit, developers migrate each capability individually.

Moving a Codex Plugin to IBM Bob

Plugin Manifest

A Codex package normally starts with:

.codex-plugin/plugin.json
Enter fullscreen mode Exit fullscreen mode

IBM Bob has no direct manifest replacement.

Instead:

  • Remove the packaging layer
  • Store configuration inside .bob/
  • Distribute project files directly through repositories or templates

Skills

Codex skills can generally be copied into:

.bob/skills/<name>/SKILL.md
Enter fullscreen mode Exit fullscreen mode

When migrating:

✅ Add name

✅ Add description

✅ Review platform-specific references

✅ Update tool names and paths

Bob only loads valid skills when running in Advanced Mode, so testing activation is important.

Lifecycle Hooks

Codex hook definitions often live inside:

hooks/hooks.json
Enter fullscreen mode Exit fullscreen mode

In IBM Bob, lifecycle events move into:

.bob/settings.json
Enter fullscreen mode Exit fullscreen mode

The actual scripts frequently remain reusable.

The main change is configuration structure and path resolution.

For example:

${PLUGIN_ROOT}
Enter fullscreen mode Exit fullscreen mode

becomes something like:

.bob/hooks/guard_write.py
Enter fullscreen mode Exit fullscreen mode

MCP Configuration

Codex plugins may define MCP servers through:

.mcp.json
Enter fullscreen mode Exit fullscreen mode

or plugin manifests.

In IBM Bob, MCP configuration is centralized inside:

.bob/mcp.json
Enter fullscreen mode Exit fullscreen mode

Migration usually requires reviewing:

  • Transport settings
  • OAuth authentication
  • Environment variables
  • Working directories
  • Tool approval settings

Never commit credentials into source control during the migration process.

AGENTS.md

One file that transfers cleanly is:

AGENTS.md
Enter fullscreen mode Exit fullscreen mode

Both Codex and IBM Bob use it for long-lived project guidance.

Repository conventions, coding policies, and workflow descriptions can often be reused with minimal changes.

Important Hook Differences

One of the biggest migration challenges involves lifecycle hooks.

Codex currently supports richer hook capabilities than Bob 2.x.

Payload Differences

Codex typically sends:

{
  "hook_event_name": "...",
  "tool_name": "...",
  "tool_input": {}
}
Enter fullscreen mode Exit fullscreen mode

IBM Bob documentation refers to:

{
  "event": "...",
  "tool": "...",
  "input": {}
}
Enter fullscreen mode Exit fullscreen mode

Creating a small adapter layer helps normalize both formats.

Tool Name Differences

Codex commonly works with:

apply_patch
Edit
Write
Enter fullscreen mode Exit fullscreen mode

Bob uses:

write_file
apply_diff
search_and_replace
insert_content
Enter fullscreen mode Exit fullscreen mode

Validation rules often need updated matchers.

Execution Model

Codex provides richer capabilities for:

  • Tool input rewriting
  • Additional context injection
  • Dynamic responses

IBM Bob focuses on deterministic control.

A typical Bob pattern is:

stderr message
+
exit code 2
Enter fullscreen mode Exit fullscreen mode

to block an operation.

This simplicity makes many validation policies portable across platforms.

Moving Claude Code Plugins to IBM Bob

Claude Code follows a similar migration path.

A typical Claude plugin may include:

.claude-plugin/plugin.json
skills/
commands/
agents/
hooks/
.mcp.json
Enter fullscreen mode Exit fullscreen mode

These components can be mapped into Bob individually.

Commands

Claude commands translate naturally to:

.bob/commands/
Enter fullscreen mode Exit fullscreen mode

Both platforms support:

  • Markdown commands
  • Descriptions
  • Arguments
  • Positional parameters

In many cases the migration is straightforward.

Agents → Personas

Claude agents generally become:

.bob/agents/
Enter fullscreen mode Exit fullscreen mode

within Bob.

Bob personas allow developers to define:

  • Specialized helper roles
  • Tool restrictions
  • Focused responsibilities

A key difference is that personas can reduce permissions but cannot elevate them.

MCP Servers

Claude MCP integrations typically move directly into:

.bob/mcp.json
Enter fullscreen mode Exit fullscreen mode

although authentication and configuration should be validated after migration.

Unsupported Components

Some Claude plugin features do not currently have direct Bob equivalents.

Examples include:

.lsp.json
Monitors
Plugin executables
Certain plugin settings
Enter fullscreen mode Exit fullscreen mode

These often require redesigning the workflow rather than performing a direct migration.

A Practical Migration Strategy

Instead of treating migration as a file-copy exercise, think of it as capability mapping:

Existing Capability IBM Bob Destination
Plugin Manifest .bob/ project config
Skills .bob/skills/
Commands .bob/commands/
Hooks .bob/settings.json
MCP Servers .bob/mcp.json
Agents .bob/agents/
Repository Rules AGENTS.md

The most portable components tend to be:

  • Skills
  • Commands
  • AGENTS.md guidance
  • PreToolUse validation hooks

These usually require only minor adjustments.

Final Thoughts

Migrating from Codex or Claude Code to IBM Bob isn't about recreating a plugin ecosystem.

It's about adopting a project-centric architecture where:

  • Skills define workflows
  • Commands standardize execution
  • Personas handle specialized roles
  • MCP extends capabilities
  • Lifecycle hooks enforce deterministic guardrails

Once you embrace these concepts, many existing AI workflows can be adapted surprisingly well.

The biggest lesson is simple:

Migrate behavior, not packaging.

Focus on the capability you're trying to preserve, then map it to the appropriate IBM Bob feature.

That approach leads to cleaner, more maintainable migrations and a better long-term developer experience.

Original concepts, examples, and migration research by Markus Eisele. This article is a summarized and paraphrased adaptation for the IBM Bob developer community.

IBMBob #Codex #ClaudeCode #AgenticAI #DeveloperTools #MCP #LifecycleHooks #AIEngineering #SoftwareEngineering #DevTools

Top comments (0)