bug: Models command incorrectly reports MCP API key status as false when keys are available #441

New issue

Open

opened 2025-10-14 15:54:46 -06:00 by navan · 0 comments

navan commented

2025-10-14 15:54:46 -06:00

Owner

Originally created by @amcharles91 on 6/22/2025

Description

The models command incorrectly reports API key status as mcp: false even when the keys
are properly configured and working. The getMcpApiKeyStatus function only checks if keys
are hardcoded in the MCP config file (.cursor/mcp.json) rather than checking if they're
actually available at runtime through environment variables, .env files, or other
sources.

This creates confusion for users who have properly configured their environment variables
but see mcp: false and think their setup isn't working.

Steps to Reproduce

Set up environment variables in Claude Code settings (~/.claude.json):
{
"mcpServers": {
"task-master-ai": {
"command": "npx",
"args": ["-y", "task-master-ai"],
"env": {
"ANTHROPIC_API_KEY": "your-key"
}
}
}
}
Run models command through MCP in Claude Code
Observe the key status shows mcp: false
Try using a feature that requires the API key (e.g., expand-task) - it works correctly

Expected Behavior

The models command should show mcp: true when API keys are available at runtime,
regardless of whether they're hardcoded in the MCP config file.

Actual Behavior

The models command shows mcp: false even when API keys are properly configured and
working, because it only checks the static MCP config file instead of runtime
availability.

Screenshots or Logs

Environment

Task Master version: 0.18.0
Node.js version: v22.16.0
Operating system: Ubuntu (WSL on Windows)
IDE: VS Code with Claude Code extension (launched from WSL terminal)

Additional Context

The issue is in the getMcpApiKeyStatus function which reads the MCP config file to check
for hardcoded keys, rather than using isApiKeySet which properly checks runtime
environment. This is a UX issue that makes users think their configuration is broken when
it's actually working fine.

Suggested fix: Either remove the MCP key status from the output, or change
getMcpApiKeyStatus to check actual runtime availability using the same logic as
isApiKeySet.

*Originally created by @amcharles91 on 6/22/2025* ### Description The models command incorrectly reports API key status as mcp: false even when the keys are properly configured and working. The getMcpApiKeyStatus function only checks if keys are hardcoded in the MCP config file (.cursor/mcp.json) rather than checking if they're actually available at runtime through environment variables, .env files, or other sources. This creates confusion for users who have properly configured their environment variables but see mcp: false and think their setup isn't working. ### Steps to Reproduce 1. Set up environment variables in Claude Code settings (~/.claude.json): { "mcpServers": { "task-master-ai": { "command": "npx", "args": ["-y", "task-master-ai"], "env": { "ANTHROPIC_API_KEY": "your-key" } } } } 2. Run models command through MCP in Claude Code 3. Observe the key status shows mcp: false 4. Try using a feature that requires the API key (e.g., expand-task) - it works correctly ### Expected Behavior The models command should show mcp: true when API keys are available at runtime, regardless of whether they're hardcoded in the MCP config file. ### Actual Behavior The models command shows mcp: false even when API keys are properly configured and working, because it only checks the static MCP config file instead of runtime availability. ### Screenshots or Logs ![Image](https://github.com/user-attachments/assets/281c5a79-4cd4-4fd1-911f-9a05cd0eeae4) ### Environment - Task Master version: 0.18.0 - Node.js version: v22.16.0 - Operating system: Ubuntu (WSL on Windows) - IDE: VS Code with Claude Code extension (launched from WSL terminal) ### Additional Context The issue is in the getMcpApiKeyStatus function which reads the MCP config file to check for hardcoded keys, rather than using isApiKeySet which properly checks runtime environment. This is a UX issue that makes users think their configuration is broken when it's actually working fine. Suggested fix: Either remove the MCP key status from the output, or change getMcpApiKeyStatus to check actual runtime availability using the same logic as isApiKeySet.