Fix startup failures caused by missing dependency, incorrect import, and missing attribute

[Suravi021]

Summary

Fixes several issues that prevented the application from starting:

• Added the missing dependency
• Corrected an invalid import
• Added the missing attribute required during initialization

Testing

• Ran the application successfully
• Ran the existing test suite
• Confirmed the original startup errors no longer occur

[qodo-code-review]

PR Summary by Qodo

Fix startup failures: add missing dependency, correct Mistral import, persist OpenAI init field

🐞 Bug fix ⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Add missing async test dependency to prevent import/startup failures.
• Fix Mistral client import to match current mistralai package layout.
• Store reasoning_effort on OpenAI provider to satisfy initialization expectations.

Diagram

graph TD
  A["App startup"] --> B["Provider init"] --> C["OpenAI LLM"] --> D["openai SDK"]
  B --> E["Mistral LLM"] --> F["mistralai SDK"]
  A --> G["Dependencies"]

  subgraph Legend
    direction LR
    _proc["Process/Component"] ~~~ _dep["Dependency"]
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Backward-compatible Mistral import fallback

• ➕ Supports multiple mistralai versions without forcing an immediate dependency/layout alignment
• ➕ Reduces risk if users have older SDKs installed in existing environments
• ➖ Adds a small amount of conditional logic/branching to provider module
• ➖ Can mask dependency drift unless paired with clear logging or version pinning

Recommendation: The PR’s direct fixes are appropriate for restoring startup quickly. If you expect mixed environments or slower dependency rollouts, consider a try/except ImportError fallback for the Mistral import (optionally with a warning) or explicitly pin/declare the supported mistralai version range so the import path is guaranteed.

Files changed (3) +3 / -1

Bug fix (2) +2 / -1

llm.pyFix Mistral client import path +1/-1

Fix Mistral client import path

• Updates the import from 'mistralai.Mistral' to 'mistralai.client.Mistral', matching the expected module structure of the installed Mistral SDK and preventing import-time startup failure.

windows_use/providers/mistral/llm.py

llm.pyPersist reasoning_effort during OpenAI provider initialization +1/-0

Persist reasoning_effort during OpenAI provider initialization

• Stores the 'reasoning_effort' argument on the provider instance ('self.reasoning_effort') so downstream initialization/usage that expects this attribute does not fail at startup.

windows_use/providers/openai/llm.py

Other (1) +1 / -0

pyproject.tomlAdd missing pytest-asyncio dependency +1/-0

Add missing pytest-asyncio dependency

• Adds 'pytest-asyncio>=1.4.0' to project dependencies to ensure the async-compatible test/runtime dependency is present in environments where startup/tests require it.

pyproject.toml

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (2) 📜 Skill insights (0)

Context used

✅ Compliance rules (platform): 11 rules

1. llm.py outside windows_use/llms 📘 Rule violation ⌂ Architecture

Description

LLM integration code was modified in windows_use/providers/.../llm.py, but the checklist requires
all LLM integration code to live under windows_use/llms. This breaks the required module boundary
for LLM client code and complicates auditing/maintenance.

Code

windows_use/providers/openai/llm.py[75]

+        self.reasoning_effort = reasoning_effort

Evidence

Rule 222813 requires LLM integration code to be placed under windows_use/llms. The modified OpenAI
and Mistral LLM implementation files are located under windows_use/providers/..., and the diff
shows new/changed LLM-related code in those locations.

Rule 222813: Place all LLM integration code in windows_use/llms directory
windows_use/providers/openai/llm.py[70-82]
windows_use/providers/mistral/llm.py[1-12]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
LLM integration code (OpenAI/Mistral client usage) is implemented/modified outside the required `windows_use/llms` directory.

## Issue Context
This PR updates LLM provider implementations in `windows_use/providers/...`, but compliance requires LLM communication/orchestration code to be centralized under `windows_use/llms`.

## Fix Focus Areas
- windows_use/providers/openai/llm.py[75-75]
- windows_use/providers/mistral/llm.py[7-7]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. uv.lock mismatches pytest-asyncio 📘 Rule violation § Compliance

Description

pyproject.toml now requires pytest-asyncio>=1.4.0, but uv.lock pins pytest-asyncio to
1.3.0. This makes the lockfile inconsistent with declared dependencies and can cause
non-reproducible installs.

Code

pyproject.toml[63]

+    "pytest-asyncio>=1.4.0"

Evidence

Rule 222815 requires using uv and keeping the uv.lock lockfile updated when dependencies change.
The diff adds pytest-asyncio>=1.4.0 to pyproject.toml, but uv.lock still pins pytest-asyncio
at 1.3.0, which violates the updated constraint.

Rule 222815: Use uv for dependency management and virtual environments
pyproject.toml[60-64]
uv.lock[3121-3133]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The dependency spec was updated, but the uv lockfile still pins an older incompatible version.

## Issue Context
`pyproject.toml` requires `pytest-asyncio>=1.4.0`, while `uv.lock` contains `pytest-asyncio` at `1.3.0`, which does not satisfy the new constraint.

## Fix Focus Areas
- pyproject.toml[60-64]
- uv.lock[3121-3133]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Duplicate pytest-asyncio requirement 🐞 Bug ☼ Reliability

Description

pyproject.toml adds pytest-asyncio to runtime dependencies even though it already exists under
the dev optional extra with a different version constraint, which can lead to inconsistent
dependency resolution and forces a test-focused dependency into normal installs.

Code

pyproject.toml[R60-64]

    "typer>=0.15.0",
    "questionary>=2.0.0",
    "cryptography>=44.0.0",
+    "pytest-asyncio>=1.4.0"
]

Evidence

The PR adds pytest-asyncio as a runtime dependency while it already exists in the dev extra with
a different constraint, and the lock/CI configuration shows the project is uv-managed and
currently only records pytest-asyncio under the dev extra metadata.

pyproject.toml[41-74]
uv.lock[4425-4430]
.github/workflows/ci.yml[30-39]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`pytest-asyncio` is declared twice with different constraints: once as a runtime dependency and once as a `dev` extra. This creates inconsistent package metadata and can change what downstream users get when they install `windows-use` without the `dev` extra.

Additionally, the repo uses `uv` in CI (`uv sync --extra dev`), and `uv.lock` currently reflects only the `dev`-extra dependency metadata for `pytest-asyncio`, not a runtime dependency, so dependency metadata is inconsistent.

### Issue Context
- `pytest-asyncio` is typically a test dependency and is already declared in `[project.optional-dependencies].dev`.
- CI uses `uv sync --extra dev`, so the project is lockfile-driven for installs.

### Fix Focus Areas
- pyproject.toml[41-74]
- uv.lock[4425-4430]
- .github/workflows/ci.yml[30-39]

### Suggested fix
1. Remove `"pytest-asyncio>=1.4.0"` from `[project].dependencies` (keep it only in `[project.optional-dependencies].dev`), **or** if it truly is required at runtime, remove it from `dev` and keep a single consistent specifier.
2. Regenerate/update and commit `uv.lock` so it matches the chosen dependency layout (runtime vs dev extra) and version constraint(s).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[qodo-code-review]

1. llm.py outside windows_use/llms 📘 Rule violation ⌂ Architecture

LLM integration code was modified in windows_use/providers/.../llm.py, but the checklist requires
all LLM integration code to live under windows_use/llms. This breaks the required module boundary
for LLM client code and complicates auditing/maintenance.

Agent Prompt

## Issue description
LLM integration code (OpenAI/Mistral client usage) is implemented/modified outside the required `windows_use/llms` directory.

## Issue Context
This PR updates LLM provider implementations in `windows_use/providers/...`, but compliance requires LLM communication/orchestration code to be centralized under `windows_use/llms`.

## Fix Focus Areas
- windows_use/providers/openai/llm.py[75-75]
- windows_use/providers/mistral/llm.py[7-7]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[qodo-code-review]

2. uv.lock mismatches pytest-asyncio 📘 Rule violation § Compliance

pyproject.toml now requires pytest-asyncio>=1.4.0, but uv.lock pins pytest-asyncio to
1.3.0. This makes the lockfile inconsistent with declared dependencies and can cause
non-reproducible installs.

Agent Prompt

## Issue description
The dependency spec was updated, but the uv lockfile still pins an older incompatible version.

## Issue Context
`pyproject.toml` requires `pytest-asyncio>=1.4.0`, while `uv.lock` contains `pytest-asyncio` at `1.3.0`, which does not satisfy the new constraint.

## Fix Focus Areas
- pyproject.toml[60-64]
- uv.lock[3121-3133]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[qodo-code-review]

3. Duplicate pytest-asyncio requirement 🐞 Bug ☼ Reliability

pyproject.toml adds pytest-asyncio to runtime dependencies even though it already exists under
the dev optional extra with a different version constraint, which can lead to inconsistent
dependency resolution and forces a test-focused dependency into normal installs.

Agent Prompt

### Issue description
`pytest-asyncio` is declared twice with different constraints: once as a runtime dependency and once as a `dev` extra. This creates inconsistent package metadata and can change what downstream users get when they install `windows-use` without the `dev` extra.

Additionally, the repo uses `uv` in CI (`uv sync --extra dev`), and `uv.lock` currently reflects only the `dev`-extra dependency metadata for `pytest-asyncio`, not a runtime dependency, so dependency metadata is inconsistent.

### Issue Context
- `pytest-asyncio` is typically a test dependency and is already declared in `[project.optional-dependencies].dev`.
- CI uses `uv sync --extra dev`, so the project is lockfile-driven for installs.

### Fix Focus Areas
- pyproject.toml[41-74]
- uv.lock[4425-4430]
- .github/workflows/ci.yml[30-39]

### Suggested fix
1. Remove `"pytest-asyncio>=1.4.0"` from `[project].dependencies` (keep it only in `[project.optional-dependencies].dev`), **or** if it truly is required at runtime, remove it from `dev` and keep a single consistent specifier.
2. Regenerate/update and commit `uv.lock` so it matches the chosen dependency layout (runtime vs dev extra) and version constraint(s).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools