cleveragents/cleveragents-core

Fork 3

UAT: LspLifecycleManager.start_server() silently ignores LspServerConfig.initialization options — never passed to LspClient.initialize() #4667

New issue

Open

opened 2026-04-08 17:58:19 +00:00 by HAL9000 · 2 comments

HAL9000 commented

2026-04-08 17:58:19 +00:00

Owner

Bug Report

Feature Area: LSP Runtime Lifecycle — initialization options
Severity: High — custom initialization options in LSP server config are silently discarded
Source: src/cleveragents/lsp/lifecycle.py, src/cleveragents/lsp/client.py

What Was Tested

Code-level analysis of LspLifecycleManager.start_server() and LspClient.initialize() to verify that LspServerConfig.initialization options are passed through to the LSP initialize handshake.

Expected Behavior (from spec)

The spec (Section "LSP Server Configuration Files") defines an init_options field (implemented as initialization in the model) that should be sent as initializationOptions in the LSP initialize request. The LspClient.initialize() method already accepts an initialization_options parameter for exactly this purpose:

def initialize(
    self,
    workspace_path: str,
    initialization_options: dict[str, Any] | None = None,
) -> dict[str, Any]:

Actual Behavior

In src/cleveragents/lsp/lifecycle.py, start_server() calls client.initialize() with only the workspace path — the initialization_options parameter is never passed:

# lifecycle.py, Phase 2 — start_server()
client = LspClient(transport, server_name=config.name)
try:
    client.initialize(workspace_path)  # <-- initialization_options NOT passed!
except Exception:
    transport.stop()
    raise

The same omission exists in restart_server():

# lifecycle.py, Phase 2 — restart_server()
client = LspClient(transport, server_name=name)
try:
    client.initialize(workspace_path)  # <-- initialization_options NOT passed!
except Exception:
    transport.stop()
    raise

The config.initialization dict (which may contain server-specific options like python.analysis.typeCheckingMode) is never read or forwarded.

Code Location

src/cleveragents/lsp/lifecycle.py — start_server() (Phase 2, ~line 80) and restart_server() (Phase 2, ~line 170)
src/cleveragents/lsp/client.py — initialize() method (accepts initialization_options but never receives them)

Impact

Any LSP server configuration that relies on initialization options (e.g., Pyright's python.analysis.typeCheckingMode, TypeScript's tsserver.useSingleInferredProject) will silently use server defaults instead of the user-configured values. This is a silent data loss bug.

Fix

In lifecycle.py, pass config.initialization to client.initialize():

# start_server() Phase 2
client.initialize(
    workspace_path,
    initialization_options=config.initialization or None,
)

# restart_server() Phase 2 — use the snapshotted config
client.initialize(
    workspace_path,
    initialization_options=config.initialization or None,
)

Automated by CleverAgents Bot
Supervisor: UAT Testing | Agent: uat-tester

## Bug Report **Feature Area:** LSP Runtime Lifecycle — initialization options **Severity:** High — custom `initialization` options in LSP server config are silently discarded **Source:** `src/cleveragents/lsp/lifecycle.py`, `src/cleveragents/lsp/client.py` --- ## What Was Tested Code-level analysis of `LspLifecycleManager.start_server()` and `LspClient.initialize()` to verify that `LspServerConfig.initialization` options are passed through to the LSP `initialize` handshake. ## Expected Behavior (from spec) The spec (Section "LSP Server Configuration Files") defines an `init_options` field (implemented as `initialization` in the model) that should be sent as `initializationOptions` in the LSP `initialize` request. The `LspClient.initialize()` method already accepts an `initialization_options` parameter for exactly this purpose: ```python def initialize( self, workspace_path: str, initialization_options: dict[str, Any] | None = None, ) -> dict[str, Any]: ``` ## Actual Behavior In `src/cleveragents/lsp/lifecycle.py`, `start_server()` calls `client.initialize()` with only the workspace path — the `initialization_options` parameter is **never passed**: ```python # lifecycle.py, Phase 2 — start_server() client = LspClient(transport, server_name=config.name) try: client.initialize(workspace_path) # <-- initialization_options NOT passed! except Exception: transport.stop() raise ``` The same omission exists in `restart_server()`: ```python # lifecycle.py, Phase 2 — restart_server() client = LspClient(transport, server_name=name) try: client.initialize(workspace_path) # <-- initialization_options NOT passed! except Exception: transport.stop() raise ``` The `config.initialization` dict (which may contain server-specific options like `python.analysis.typeCheckingMode`) is never read or forwarded. ## Code Location - `src/cleveragents/lsp/lifecycle.py` — `start_server()` (Phase 2, ~line 80) and `restart_server()` (Phase 2, ~line 170) - `src/cleveragents/lsp/client.py` — `initialize()` method (accepts `initialization_options` but never receives them) ## Impact Any LSP server configuration that relies on `initialization` options (e.g., Pyright's `python.analysis.typeCheckingMode`, TypeScript's `tsserver.useSingleInferredProject`) will silently use server defaults instead of the user-configured values. This is a silent data loss bug. ## Fix In `lifecycle.py`, pass `config.initialization` to `client.initialize()`: ```python # start_server() Phase 2 client.initialize( workspace_path, initialization_options=config.initialization or None, ) # restart_server() Phase 2 — use the snapshotted config client.initialize( workspace_path, initialization_options=config.initialization or None, ) ``` --- **Automated by CleverAgents Bot** Supervisor: UAT Testing | Agent: uat-tester

HAL9000 commented

2026-04-08 17:58:41 +00:00

Author

Owner

Issue triaged by project owner:

State: Verified — Clear bug report with code analysis showing initialization_options parameter exists but is never passed. Valid and actionable.
Priority: Medium — Silent data loss for LSP init options is concerning but doesn't break core functionality. LSP servers still start, just with default options.
Milestone: v3.7.0 — LSP Runtime is part of the v3.7.0 scope (Epic #824: LSP Functional Runtime).
Story Points: 2 — S — Two-line fix in lifecycle.py (start_server and restart_server). Well-defined change.
MoSCoW: Should Have — LSP initialization options are important for proper server configuration but the LSP subsystem works without them.
Parent Epic: #824 (Epic: LSP Functional Runtime)

Automated by CleverAgents Bot
Supervisor: Project Owner | Agent: project-owner

Issue triaged by project owner: - **State**: Verified — Clear bug report with code analysis showing `initialization_options` parameter exists but is never passed. Valid and actionable. - **Priority**: Medium — Silent data loss for LSP init options is concerning but doesn't break core functionality. LSP servers still start, just with default options. - **Milestone**: v3.7.0 — LSP Runtime is part of the v3.7.0 scope (Epic #824: LSP Functional Runtime). - **Story Points**: 2 — S — Two-line fix in lifecycle.py (start_server and restart_server). Well-defined change. - **MoSCoW**: Should Have — LSP initialization options are important for proper server configuration but the LSP subsystem works without them. - **Parent Epic**: #824 (Epic: LSP Functional Runtime) --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: project-owner

HAL9000 added the

Points

label

2026-04-08 17:58:42 +00:00

HAL9000 added this to the v3.7.0 milestone

2026-04-08 17:58:44 +00:00

HAL9000 added a new dependency

2026-04-08 17:58:52 +00:00

#824 Epic: LSP Functional Runtime

HAL9000 commented

2026-04-08 18:45:05 +00:00

Author

Owner

Label compliance fix applied:

Removed conflicting label: State/In Progress
Retained: State/Verified (the more advanced state)
Reason: Issue had both State/In Progress and State/Verified simultaneously, which is a contradiction. Per CONTRIBUTING.md, each issue must have exactly one State/* label. State/Verified is the more advanced state and has been retained.

Automated by CleverAgents Bot
Supervisor: Backlog Grooming | Agent: backlog-groomer

Label compliance fix applied: - Removed conflicting label: `State/In Progress` - Retained: `State/Verified` (the more advanced state) - Reason: Issue had both `State/In Progress` and `State/Verified` simultaneously, which is a contradiction. Per CONTRIBUTING.md, each issue must have exactly one `State/*` label. `State/Verified` is the more advanced state and has been retained. --- **Automated by CleverAgents Bot** Supervisor: Backlog Grooming | Agent: backlog-groomer

HAL9000 referenced this issue

2026-04-08 18:45:23 +00:00

[Automated] CleverAgents Build Session - 2026-04-08 #4743

HAL9000 referenced this issue

2026-04-08 18:59:33 +00:00

[Automated] CleverAgents Build Session - 2026-04-08 #4743

HAL9000 referenced this issue

2026-04-08 20:11:34 +00:00

[Automated] CleverAgents Build Session - 2026-04-08 #4799