CodeClone version
2.0.0b6
MCP category
Packaging / launcher / transport
MCP client or host
uv tool / uv pip prerelease install flow for codeclone[mcp]; affects codeclone-mcp startup before any client-specific tool call.
What happened?
Installing the optional MCP extra with a prerelease-enabled resolver can select httpx 1.0.dev* through the MCP dependency graph. That build is incompatible with the current MCP runtime expectations and causes codeclone-mcp startup/import failure.
The base codeclone package is unaffected. Non-prerelease installs resolve a compatible stable httpx release and work as expected. The failure matters because CodeClone beta install instructions commonly use --pre, so this can affect the documented MCP install path.
What should happen instead?
The codeclone[mcp] extra should remain installable even when the outer installer uses --pre for CodeClone itself.
CodeClone should constrain the optional MCP extra to a stable compatible httpx range, e.g. httpx>=0.27.1,<1, so prerelease install flows do not accidentally resolve incompatible httpx 1.0.dev* builds.
Reproduction or request sequence
{
"commands": [
"uv tool install --pre \"codeclone[mcp]\"",
"codeclone-mcp --help"
],
"observed": "The MCP launcher can fail during import/startup when httpx 1.0.dev* is resolved.",
"representative_error": "AttributeError: module 'httpx' has no attribute 'TransportError'",
"expected": "codeclone-mcp starts normally and uses a stable httpx 0.x release."
}
Additional context
Planned/fixed in 2.0.0b7 as a packaging-only hotfix by adding a direct httpx>=0.27.1,<1 constraint to the optional MCP extra.
This does not change MCP tool schemas, report contracts, baseline/cache semantics, or runtime behavior once the server starts. It only makes the documented prerelease install path deterministic and safe.
CodeClone version
2.0.0b6
MCP category
Packaging / launcher / transport
MCP client or host
uv tool / uv pip prerelease install flow for codeclone[mcp]; affects codeclone-mcp startup before any client-specific tool call.
What happened?
Installing the optional MCP extra with a prerelease-enabled resolver can select httpx 1.0.dev* through the MCP dependency graph. That build is incompatible with the current MCP runtime expectations and causes codeclone-mcp startup/import failure.
The base codeclone package is unaffected. Non-prerelease installs resolve a compatible stable httpx release and work as expected. The failure matters because CodeClone beta install instructions commonly use --pre, so this can affect the documented MCP install path.
What should happen instead?
The codeclone[mcp] extra should remain installable even when the outer installer uses --pre for CodeClone itself.
CodeClone should constrain the optional MCP extra to a stable compatible httpx range, e.g. httpx>=0.27.1,<1, so prerelease install flows do not accidentally resolve incompatible httpx 1.0.dev* builds.
Reproduction or request sequence
{ "commands": [ "uv tool install --pre \"codeclone[mcp]\"", "codeclone-mcp --help" ], "observed": "The MCP launcher can fail during import/startup when httpx 1.0.dev* is resolved.", "representative_error": "AttributeError: module 'httpx' has no attribute 'TransportError'", "expected": "codeclone-mcp starts normally and uses a stable httpx 0.x release." }Additional context
Planned/fixed in 2.0.0b7 as a packaging-only hotfix by adding a direct httpx>=0.27.1,<1 constraint to the optional MCP extra.
This does not change MCP tool schemas, report contracts, baseline/cache semantics, or runtime behavior once the server starts. It only makes the documented prerelease install path deterministic and safe.