pingdotgg / pingdotgg/t3code

Claude provider probe fails with enterprise-managed MCP configuration

Open
#5,392 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
23k
Forks
5.9k
Avg merge
11h 14m
Merged PRs (30d)
357

Description

Area

Claude provider / authentication detection

Steps to reproduce
  1. Use Claude Code on macOS with an enterprise-managed MCP configuration at:

    /Library/Application Support/ClaudeCode/managed-mcp.json

  2. Confirm that Claude Code is authenticated and works normally:

    claude auth status
    claude
    
  3. Enable Claude in T3 Code and configure the native Claude binary.

  4. Refresh the provider status or restart T3 Code.

Expected behavior

T3 Code recognizes the authenticated Claude installation and makes the Claude provider available.

Actual behavior

T3 Code detects the Claude executable and its version, but reports:

Could not verify Claude authentication status from initialization result.

Reproducing the capability probe directly with the Claude Agent SDK bundled in T3 Code produces:

You cannot use --strict-mcp-config when an enterprise MCP config is present

The capability probe is started with an empty MCP configuration and strict MCP mode enabled. When an enterprise-managed MCP configuration is present, Claude exits before returning initialization or account information.

Claude remains authenticated and fully usable when run normally from the terminal.

Context

The strict MCP isolation addresses the failure mode reported in #3909, where the periodic capability probe loaded user-configured MCP servers and repeatedly started their processes.

However, the same isolation prevents the capability probe from starting when Claude is governed by an enterprise-managed MCP configuration. This inadvertently makes T3 Code unable to recognize affected enterprise Claude installations.

A related compatibility concern may apply to #4062, which proposes using --strict-mcp-config for headless Claude text generation. Claude rejects that flag when enterprise-managed MCP configuration is present, so the same behavior may affect that path if the change is merged unchanged.

Impact

Claude cannot be selected through T3 Code on affected enterprise-managed machines, despite the CLI being installed, authenticated, and otherwise fully functional.

Version
  • T3 Code: 0.0.32-nightly.20260805.1002
  • Claude Code: 2.1.222
  • Platform: macOS arm64
  • T3 installation: Desktop nightly
  • Claude installation: Native Claude Code binary
Relevant diagnostic output
You cannot use --strict-mcp-config when an enterprise MCP config is present

T3 Code replaces this underlying error with the generic authentication-status warning.

Workaround

No supported workaround found that preserves the enterprise-managed MCP configuration.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at the Claude capability probe that invokes the bundled Claude Agent SDK and reproduces the enterprise-managed MCP error with --strict-mcp-config. Trace how that initialization failure becomes the generic authentication warning; done means an authenticated enterprise-managed Claude installation is recognized without loading its MCP servers, with the probe behavior verified against the reported diagnostic.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
authentication
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.