Fransiscus Setiawan

Technical articles on AI agents, Azure, .NET, architecture, and EV charging systems from Sydney.

Category: MCP Servers

How to Configure Claude Code with Kimi K2, DeepSeek, and GLM: Complete WSL Setup Guide

By

On September 23, 2025

In AI & Agents, MCP Servers

Claude Code is a powerful CLI tool that can be configured to work with multiple AI providers beyond Anthropic’s default endpoints. In this comprehensive guide, you’ll learn how to set up Claude Code configuration with three popular AI providers: Kimi K2, DeepSeek, and GLM, all while using Windows Subsystem for Linux (WSL).

Prerequisites

  • Windows 10/11 with WSL installed
  • Claude Code CLI installed
  • API tokens for Kimi K2, DeepSeek, and/or GLM
  • Basic familiarity with bash commands

Why Use Multiple AI Providers with Claude Code?

Different AI providers offer unique advantages:

  • Kimi K2: Excellent for Chinese language processing and local deployment options
  • DeepSeek: Strong performance in coding tasks and mathematical reasoning
  • GLM: Optimized for conversational AI and general-purpose tasks

Step 1: Create Environment Files for Each AI Provider

First, we’ll create separate environment files for each AI provider to store their API configurations securely.

Creating the Kimi K2 Environment File

Create the ~/.claude-kimi-env file:

export ANTHROPIC_BASE_URL="https://api.moonshot.cn/v1"
export ANTHROPIC_AUTH_TOKEN="your_kimi_token_here"

Creating the DeepSeek Environment File

Create the ~/.claude-deepseek-env file:

export ANTHROPIC_BASE_URL="https://api.deepseek.com/v1"
export ANTHROPIC_AUTH_TOKEN="your_deepseek_token_here"

Creating the GLM Environment File

Create the ~/.claude-glm-env file:

export ANTHROPIC_BASE_URL="https://api.z.ai/api/anthropic"
export ANTHROPIC_AUTH_TOKEN="your_glm_token_here"

Step 2: Set Up Convenient Aliases

To make switching between AI providers seamless, we’ll create bash aliases that automatically load the correct environment and launch Claude Code.

Create or edit the ~/.bash_aliases file and add the following aliases:

# Custom aliases

  # Claude GLM alias
  alias claude-glm='source ~/.claude-glm-env && claude --dangerously-skip-permissions'

  # Claude Kimi alias
  alias claude-kimi='source ~/.claude-kimi-env && claude --dangerously-skip-permissions'

  # Claude DeepSeek alias
  alias claude-deepseek='source ~/.claude-deepseek-env && claude --dangerously-skip-permissions'

  # Add more aliases below this line

Step 3: Ensure Aliases Load Automatically in WSL

For the aliases to work every time you start WSL, verify that your ~/.bashrc file includes the following lines (they should be there by default):

if [ -f ~/.bash_aliases ]; then
      . ~/.bash_aliases
  fi

Step 4: Apply the Configuration

To use the new aliases immediately without restarting WSL, run:

source ~/.bash_aliases

How to Use Your New Claude Code Setup

Now you can easily switch between AI providers using simple commands:

  • claude-kimi – Launch Claude Code with Kimi K2
  • claude-deepseek – Launch Claude Code with DeepSeek
  • claude-glm – Launch Claude Code with GLM

Security Best Practices

Important Security Tips:

  • Never commit environment files to version control
  • Use strong, unique API tokens for each provider
  • Regularly rotate your API keys
  • Set appropriate file permissions: chmod 600 ~/.claude-*-env

Troubleshooting Common Issues

Aliases Not Working

If your aliases aren’t working after starting WSL:

  1. Check if ~/.bash_aliases exists
  2. Verify ~/.bashrc sources the aliases file
  3. Run source ~/.bashrc to reload the configuration

API Connection Issues

If you encounter API connection problems:

  • Verify your API tokens are correct
  • Check if the API endpoints are accessible from your network
  • Ensure the base URLs are properly formatted

Advanced Configuration Tips

Adding Model-Specific Parameters

You can extend your environment files to include model-specific parameters:

export ANTHROPIC_BASE_URL="https://api.deepseek.com/v1"
  export ANTHROPIC_AUTH_TOKEN="your_token"
  export ANTHROPIC_MODEL="deepseek-chat"

Creating Project-Specific Configurations

For different projects, you might want different AI providers. Consider creating project-specific environment files and aliases.

Conclusion

You’ve successfully configured Claude Code to work with multiple AI providers on Windows WSL. This setup gives you the flexibility to choose the best AI provider for each task while maintaining a consistent development workflow.

The combination of environment files and bash aliases provides a clean, secure, and efficient way to manage multiple AI provider configurations. Whether you’re working with Kimi K2’s Chinese language capabilities, DeepSeek’s coding expertise, or GLM’s conversational strengths, you can now switch between them effortlessly.

Fixing “spawn npx ENOENT” in Windows 11 When Adding MCP Server with Node/NPX

By

On April 22, 2025

In AI & Agents, MCP Servers

If you’re running into the error:

spawn npx ENOENT

while configuring an MCP (Multi-Context Plugin) server on Windows 11, you’re not alone. This error commonly appears when integrating tools like @upstash/context7-mcp using Node.js environments that rely on NPX, especially in cross-platform development.

This post explains:

  • What causes the “spawn npx ENOENT” error on Windows
  • The difference between two MCP server configuration methods
  • A working fix using cmd /c
  • Why this issue is specific to Windows

The Problem: “spawn npx ENOENT”

Using this configuration in your .mcprc.json or a similar setup:

{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp@latest"]
    }
  }
}

will cause the following error on Windows:

spawn npx ENOENT

This indicates that Node.js tried to spawn npx but couldn’t locate it in the system’s PATH.

Root Cause: Windows vs Unix Shell Behavior

On UNIX-like systems (Mac/Linux), spawn can run shell commands like npx directly. But Windows behaves differently:

  • Windows expects a .exe file to be explicitly referenced when spawning a process.
  • npx is not a native binary executable; it requires a shell to interpret and run it.
  • Node’s child_process.spawn does not invoke a shell by default unless specifically instructed.

In the failing example, the system tries to invoke npx directly as if it were a standalone executable, which doesn’t work on Windows.

The Fix: Wrapping with cmd /c

This configuration solves the issue:

{
  "context7": {
    "command": "cmd",
    "args": [
      "/c",
      "npx",
      "-y",
      "@upstash/context7-mcp@latest"
    ]
  }
}

Explanation

  • "cmd" invokes the Windows Command Prompt.
  • "/c" tells the shell to execute the command that follows.
  • The rest of the line (npx -y @upstash/context7-mcp@latest) is interpreted and executed properly by the shell.

This ensures that npx is resolved correctly and executed within a compatible environment.

Technical Comparison

Configuration Style Works on Windows? Shell Used? Reason
"command": "npx" No No Tries to execute npx directly without shell
"command": "cmd", "args": ["/c", "npx", ...] Yes Yes Executes the command within the Windows shell, allowing proper resolution

Best Practices

When using Node.js-based CLI tools across platforms:

  • Wrap shell commands using cmd /c (Windows) or sh -c (Unix)
  • Avoid assuming that commands like npx are executable as binaries
  • Test your scripts in both Windows and Unix environments when possible

Conclusion

If you’re encountering the spawn npx ENOENT error when configuring MCP servers on Windows 11, the fix is straightforward: use cmd /c to ensure shell interpretation. This small change ensures compatibility and prevents runtime errors across different operating systems.

Powered by WordPress & Theme by Anders Norén