#2481·mcp-use

fix(python): CodeExecutor reports zero execution_time on Windows

Author: OT-WuLongCreated Sep 8, 2026Updated Sep 8, 2026
LabelsbugPythonclientdependenciesmcp-use/mcp-use

Describe the bug

CodeExecutor.execute() frequently reports an execution_time of exactly 0.0 for short executions on Windows.

I discovered this while setting up the repository and running the documented Python unit-test command:

powershell
pytest tests/unit

The test suite returned:

304 passed, 1 failed

The failure was:

tests/unit/test_code_executor.py::TestCodeExecutorBasics::test_execute_simple_code

assert result["execution_time"] > 0
E assert 0.0 > 0

CodeExecutor.execute() currently measures elapsed time using time.time(). On this Windows environment, that clock has a resolution of approximately 15.625 milliseconds, so short executions often start and finish within the same clock tick.

To Reproduce

  1. Clone the repository and enter the Python package:
powershell
git clone https://github.com/mcp-use/mcp-use.git
cd mcp-use\libraries\python
  1. Create a virtual environment and install the development dependencies:
powershell
uv venv
uv pip install --python .\.venv\Scripts\python.exe -e ".[dev,anthropic,openai,search,e2b]"
  1. Run the affected test:
powershell
.\.venv\Scripts\python.exe -m pytest -q tests\\\unit\test_code_executor.py::TestCodeExecutorBasics::test_execute_simple_code
  1. Repeat the test to expose the platform-dependent failure:
powershell
$passed = 0
$failed = 0

1..12 | ForEach-Object {
    .\.venv\Scripts\python.exe -m pytest -q `
        tests\\\unit\test_code_executor.py::TestCodeExecutorBasics::test_execute_simple_code

    if ($LASTEXITCODE -eq 0) {
        $passed++
    } else {
        $failed++
    }
}

Write-Output "passed=$passed failed=$failed"

Observed on my machine:

passed=2 failed=10

Expected behavior

execution_time should be measured with a monotonic, high-resolution clock and should retain useful timing information for short executions.

The result should remain a floating-point number expressed in seconds, without changing the existing return structure, timeout behavior, or error handling.

Screenshots

Not applicable. The failure is visible in the pytest output included above.

Desktop (please complete the following information):

  • OS: Windows x86_64
  • Browser: Not applicable
  • Version: Python 3.11.9, mcp-use 1.7.0, repository commit 08bbc7a1dcd84bbafbae7f19633ae25fa5e0774b

Smartphone (please complete the following information):

  • Device: Not applicable
  • OS: Not applicable
  • Browser: Not applicable
  • Version: Not applicable

Additional context

The relevant implementation currently uses the wall clock:

python
start_time = time.time()
...
execution_time = time.time() - start_time

Clock information on the affected machine:

time:
  implementation = GetSystemTimeAsFileTime()
  monotonic = False
  adjustable = True
  resolution = 0.015625

perf_counter:
  implementation = QueryPerformanceCounter()
  monotonic = True
  adjustable = False
  resolution = 1e-07

I plan to replace the two time.time() calls with time.perf_counter(), which is designed for measuring short durations.

I will also make the existing test deterministic by mocking perf_counter() with known start and end values instead of relying on the host machine’s clock resolution.

The proposed change is limited to:

  • libraries/python/mcp_use/client/code_executor.py
  • libraries/python/tests/unit/test_code_executor.py

No dependencies or public APIs will change. The prepared fix passes all 305 Python unit tests and the Ruff lint and format checks. A PR will be submitted shortly.