Repository navigation
# Feature Request: Support for Custom Claude Code Execution Command and Environment Variables #400
Description
Problem Description
I'm using claude-code-router (CCR), a proxy tool that routes Claude Code requests to different AI models and providers. However, opcode currently doesn't support integration with CCR due to the following limitations:
- Hardcoded
claudecommand: opcode directly calls theclaudebinary without allowing customization - Environment variable whitelist: The code (
src-tauri/src/commands/claude.rs) only inherits specific environment variables (PATH, HOME, NODE_*, etc.) and filters out critical ones needed by CCR like:ANTHROPIC_BASE_URLCLAUDE_CODE_MAX_OUTPUT_TOKENSMAX_THINKING_TOKENS
Current Workaround Attempts
I tried creating a wrapper script to intercept claude calls, but ran into issues:
- Direct call + environment variables: Doesn't work because CCR's managed authentication requires going through
ccr codecommand - Wrapper calling
ccr code: Creates infinite loop (claude→ccr code→claude→ ...)
Proposed Solutions
Option 1: Custom Claude Binary Path (Recommended)
Add a setting in opcode UI to specify a custom Claude Code launch command:
UI Example:
Settings → General → Claude Code Command
[ccr code ] (default: claude)
Implementation:
// In src-tauri/src/commands/claude.rs
let claude_command = get_custom_claude_command().unwrap_or("claude".to_string());
let mut cmd = Command::new(claude_command);Option 2: Custom Environment Variables
Add a setting to specify additional environment variables:
UI Example:
Settings → Advanced → Custom Environment Variables
┌──────────────────────────────────────────────┐
│ ANTHROPIC_BASE_URL=https://my-proxy.com/ │
│ CLAUDE_CODE_MAX_OUTPUT_TOKENS=20000 │
└──────────────────────────────────────────────┘
Implementation:
// In create_command_with_env()
let custom_envs = get_custom_environment_variables();
for (key, value) in custom_envs {
cmd.env(key, value);
}Option 3: Whitelist Configuration
Allow users to extend the environment variable whitelist via config file or UI.
Use Cases
This feature would benefit users who:
- Use CCR to route requests to different AI models (e.g., Gemini, DeepSeek, Ollama)
- Run Claude Code through custom proxy servers
- Need to set custom API endpoints for enterprise deployments
- Want to modify Claude Code behavior via environment variables
Related Code
The relevant code is in src-tauri/src/commands/claude.rs:
fn create_command_with_env() {
// Current whitelist only includes:
if key == "PATH" || key == "HOME" || key == "USER" || key == "SHELL"
|| key == "LANG" || key == "LC_ALL" || key.starts_with("LC_")
|| key == "NODE_PATH" || key == "NVM_DIR" || key == "NVM_BIN"
|| key == "HOMEBREW_PREFIX" || key == "HOMEBREW_CELLAR"
{
// Only these variables are inherited
}
}Additional Context
- CCR GitHub: https://github.com/musistudio/claude-code-router
- CCR Usage:
ccr code --model <model> "prompt"instead ofclaude "prompt" - opcode Version: Latest from main branch
- OS: macOS 14+
Expected Behavior
After implementing one of the proposed solutions, users should be able to:
- Configure opcode to use
ccr codeinstead ofclaude - Pass custom environment variables to Claude Code
- Successfully integrate opcode with CCR and similar proxy tools
Thank you for considering this feature! opcode is an excellent tool, and this enhancement would make it compatible with the broader Claude Code ecosystem.
Activity
docs: add Windows/WSL support research summary
HerShin5 commentedon Jun 8, 2026
Option 2 would unblock a lot of gateway setups, especially when users run Claude Code through CCR or another Anthropic↔OpenAI-compatible bridge.
I’d suggest allowing an explicit, user-controlled env allowlist for variables like
ANTHROPIC_BASE_URL,OPENAI_BASE_URL, provider API keys, and model/max-token settings. That keeps the integration flexible without inheriting the entire host environment.As one test case, KiroForge exposes an OpenAI-compatible endpoint at
https://kiroforge.cloud/v1; it would be useful to verify that opcode can launch a routed Claude Code workflow where the bridge targets that upstream.houleixx commentedon Jun 22, 2026
+1 for allowing both a custom launch command and explicit env passthrough.
ccglass depends on the same mechanism: it starts a local logging proxy, then launches Claude Code with
ANTHROPIC_BASE_URLpointed at that proxy. If an appstrips or overrides this env var, Claude Code silently talks to the upstream API directly and the dashboard stays empty.
So this is not only useful for CCR. It also enables local observability/debugging tools, enterprise gateways, budget controls, and request inspection without
patching Claude Code itself.
For validation, a tiny canary would be enough: launch Claude through opcode with
ANTHROPIC_BASE_URL=http://127.0.0.1:<port>, run one prompt, and confirm thelocal proxy sees
/v1/messages.