From Terminal to Production: Feature Flag Automation with Claude Code and Unleash

The first post in this series covered why connecting Claude Code to your feature flag system matters.

This post is the hands-on follow-up. We will start where every developer starts (the terminal) and work our way to production. By the end, you will have a working Unleash MCP integration, policy files that encode your team’s conventions, piped workflows for batch operations, and a CI/CD pipeline that reviews every PR for missing feature flags.

Part 1: The Terminal

What You Need

The Unleash MCP server runs locally and communicates with Claude Code via the Model Context Protocol. Claude Code supports MCP across all its interfaces: terminal CLI, VS Code extension, JetBrains plugin, and desktop app. But this guide starts with the terminal CLI since that is Claude Code’s native environment.

You will need:

• Node.js 18+ for running the MCP server via npx
• Claude Code installed (instructions here)
• An Unleash instance with API access (cloud or self-hosted)
• A Personal Access Token with permissions to create and manage flags

Installing the MCP Server

You can add the Unleash MCP server using the CLI command or by creating a configuration file manually.

Option 1: CLI command

claude mcp add --transport stdio --scope project unleash \
  -e UNLEASH_BASE_URL='${UNLEASH_BASE_URL}' \
     UNLEASH_PAT='${UNLEASH_PAT}' \
     UNLEASH_DEFAULT_PROJECT='${UNLEASH_DEFAULT_PROJECT:-default}' \
  -- npx -y @unleash/mcp@latest --log-level error

Note the syntax: the server name comes before the -e flag, and multiple environment variables are space-separated after a single -e. Using –-scope project stores the configuration in .mcp.json at your project root.

Option 2: Manual configuration

Create a .mcp.json file at your project root:

{
  "mcpServers": {
    "unleash": {
      "command": "npx",
      "args": ["-y", "@unleash/mcp@latest", "--log-level", "error"],
      "env": {
        "UNLEASH_BASE_URL": "${UNLEASH_BASE_URL}",
        "UNLEASH_PAT": "${UNLEASH_PAT}",
        "UNLEASH_DEFAULT_PROJECT": "${UNLEASH_DEFAULT_PROJECT:-default}"
      }
    }
  }
}

Both approaches create the same .mcp.json file at your project root, which can be committed to version control since it contains no credentials. The ${VAR} syntax tells Claude Code to expand environment variables at runtime.

Setting Up Credentials

Claude Code expands environment variables at runtime. The cleanest approach is to source credentials from your shell profile.

Create a credentials file:

mkdir -p ~/.unleash
cat > ~/.unleash/mcp.env << 'EOF'
UNLEASH_BASE_URL=https://your-instance.getunleash.io/api
UNLEASH_PAT=your-personal-access-token
UNLEASH_DEFAULT_PROJECT=default
EOF
chmod 600 ~/.unleash/mcp.env

Add to your ~/.zshrc or ~/.bashrc:

if [ -f ~/.unleash/mcp.env ]; then
  source ~/.unleash/mcp.env
  export UNLEASH_BASE_URL UNLEASH_PAT UNLEASH_DEFAULT_PROJECT
fi

Restart your terminal or run source ~/.zshrc. Now the .mcp.json file references variables that expand at runtime, keeping credentials out of version control.

Verifying the setup

Check that the server is configured correctly:

claude mcp get unleash

You should see output showing the server name, command, and scope.

Start a Claude Code session and run /mcp to see connected servers. You should see the Unleash server with nine available tools: evaluate_change, detect_flag, create_flag, wrap_change, get_flag_state, set_flag_rollout, toggle_flag_environment, remove_flag_strategy, and cleanup_flag.

Part 2: The Team

You have a working setup. Now the question is: how do you make sure every developer on the team follows the same feature flag conventions?

Encoding policies with CLAUDE.md

You can encode your team’s FeatureOps policies in a CLAUDE.md file at the project root, and Claude Code will apply them automatically. This is not just documentation. Claude Code reads this file and follows its guidance.

Create a CLAUDE.md file with your feature flag conventions:

# Project Instructions

## Feature Flag Guidelines

When making changes to this codebase:

1. **Always evaluate risk** – Before implementing changes to payments, authentication, data migrations, or external integrations, use the Unleash MCP server to evaluate whether a feature flag is needed.

2. **Naming conventions** – Use the format `{domain}-{feature}-{variant}`. Examples: `checkout-stripe-integration`, `auth-sso-google`, `api-rate-limiting`.

3. **Flag types**:
   - `release` – For gradual feature rollouts
   - `experiment` – For A/B tests
   - `operational` – For system behavior toggles
   - `kill-switch` – For emergency shutdowns

4. **Check before creating** – Always check for existing flags before creating new ones using detect_flag.

5. **Clean up after rollout** – Once a feature is at 100% for 2+ weeks, use cleanup_flag to remove dead code.

Now when a developer asks Claude Code to add Stripe payment processing, it will automatically consider whether a feature flag is needed without being explicitly asked. The policies are embedded in the conversation context.

For larger teams, you can add domain-specific rules:

### Domain-specific rules

- **Payments domain** (`src/payments/`): Always require flags for any changes.
- **UI components** (`src/components/`): Flags optional for styling, required for behavior.
- **API endpoints** (`src/api/`): Require flags for breaking changes.

### Rollout defaults

When using set_flag_rollout, apply these defaults:
- Start at 10%
- Wait 24 hours before advancing
- Pause if error rate exceeds 1%

Your First Feature Flag Workflow

With policies in place, let’s walk through the core workflow. It uses four tools in sequence:

1. evaluate_change: Determine if a flag is needed
2. detect_flag: Check if a similar flag already exists
3. create_flag: Create the flag with proper naming
4. wrap_change: Generate framework-specific guard code

In the terminal, tell Claude Code what you are working on:

Evaluate whether the Stripe payment integration should be behind a feature flag. The change touches the checkout service.

Claude Code calls evaluate_change. Based on your CLAUDE.md policies (payments domain always requires flags), it will recommend a flag. It then calls detect_flag to check for duplicates. If none exist, it calls create_flag with a name matching your conventions (e.g., checkout-stripe-integration), then wrap_change to generate the guard code.

The generated code matches your framework:

if (unleash.isEnabled('checkout-stripe-integration', context)) {
  // New Stripe payment flow
  await stripeService.processPayment(req.body);
} else {
  // Existing payment flow
  await legacyPaymentService.process(req.body);
}

Accept, adjust, and commit.

Building team knowledge with memory

Claude Code’s /memory command saves context that persists across sessions. Use it to record FeatureOps decisions:

# After granting a naming exception
/memory "Exception: 'legacy-auth-bypass' uses legacy naming because it wraps pre-existing code."

# After a successful rollout strategy
/memory "The 10-25-50-100 rollout with 24h holds worked well for checkout-redesign. Use as default for UI changes."

Memory is personal and cross-project. For shared policies, use CLAUDE.md. For individual learnings, use /memory. Keep in mind that Claude’s memory is stored in a local file such as .claude/memory.md that you can edit and clean up over time, as the system evolves.

Part 3: Production

You have a local workflow and team policies. The final step is scaling this beyond interactive sessions — batch operations, pre-commit hooks, and CI/CD.

Piped Workflows for Batch Operations

Claude Code’s pipe-friendly interface opens up powerful batch operations. You can combine standard Unix tools with Claude Code to process data that the MCP server cannot access directly.

Find commits that should have been flagged

git log --oneline -20 | claude -p "Review these commits. For each, use evaluate_change to determine if it should have been feature flagged. Report gaps."

Analyze a diff before merging

git diff main...feature-branch | claude -p "Analyze this diff. Use evaluate_change to determine which changes need feature flags."

Pre-commit hook for flag evaluation

# In .git/hooks/pre-commit
git diff --cached | claude -p "Evaluate this staged diff for feature flag requirements" --output-format json

Find flag references in code and check their state

grep -r "isEnabled\|is_enabled" src/ | claude -p "Extract flag names from these references. Use get_flag_state to check if each exists in Unleash and report mismatches."

For operations that only need Unleash data, skip the pipe and ask directly. Claude Code uses the MCP tools:

claude -p "List all feature flags and identify any that haven't been modified in 90 days"

CI/CD: Automated Flag Reviews on Every PR

Piped workflows are great for ad-hoc batch work. For systematic coverage, run Claude Code in CI/CD. The @anthropics/claude-code-action GitHub Action makes this straightforward:

jobs:
  flag-review:
    runs-on: ubuntu-latest
    steps:
      - name: Create MCP Config
        run: |
          cat > /tmp/mcp-config.json << 'EOF'
          {
            "mcpServers": {
              "unleash": {
                "command": "npx",
                "args": ["-y", "@unleash/mcp@latest"],
                "env": {
                  "UNLEASH_BASE_URL": "${{ secrets.UNLEASH_BASE_URL }}",
                  "UNLEASH_PAT": "${{ secrets.UNLEASH_PAT }}"
                }
              }
            }
          }
          EOF

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          claude_args: |
            --mcp-config /tmp/mcp-config.json
            --allowedTools mcp__unleash__evaluate_change,mcp__unleash__wrap_change
          prompt: "Review this PR for high-risk changes that should be flagged"

For headless automation outside of GitHub Actions, use the –print flag:

claude --print --allowedTools "mcp__unleash__*" "Audit flags and generate a cleanup report" > report.md

What’s Next

You have gone from a terminal setup to team policies to production CI/CD — and every step builds on the one before it. The .mcp.json and CLAUDE.md files you committed mean every developer on the team gets the same integration and the same policies without extra setup.

From here:

• Expand policies — Add domain-specific rules as your team learns what works
• Harden CI/CD — Add the flag review workflow to more repositories
• Build habits — Use /memory to record rollout strategies that worked well
• Clean up regularly — Schedule monthly flag audits using piped workflows

For the full technical reference, including VS Code, JetBrains, and desktop app setup, see the Claude Code integration documentation. The Unleash MCP server repository has additional examples and configuration options.