Allow editing projects while Studio Pro stays open (SQLite write-lock blocks develop→verify cycle)

[ako]

Problem

Studio Pro must be closed before mxcli can modify a project, which makes the develop-then-verify cycle cumbersome: every change requires close SP → run mxcli → reopen SP to verify.

Why this happens

For MPR v1 (single SQLite file) two writers are guaranteed to conflict; even for v2 (mprcontents/) both processes must update the shared SQLite _units table. mxcli already mitigates lock contention on its own side (sdk/mpr/reader.go:95-100: SetMaxOpenConns(1) + PRAGMA busy_timeout=5000), but it cannot coexist with a Studio Pro write lock. See docs/11-proposals/PROPOSAL_concurrent_access.md.

Request

Allow model edits while Studio Pro stays open — or expose mxcli / Claude from Studio Pro's chat interface.

Status / path forward

This is the motivation for the MCP backend (docs/11-proposals/PROPOSAL_mcp_backend.md, Phase 0 complete, Phases 1–3 pending): route writes through Studio Pro's MCP server (http://localhost:7782/mcp, 11.11+) so SP itself serializes the BSON and stays open. This issue tracks the user-facing requirement; the proposal tracks the implementation.

---

Source: customer feedback batch (2026-06). Reporter: Miwa. Reporter severity: 5/5.
Filed after codebase investigation at 297e0b0a.

[github-actions]

Issue Triage

Summary
The issue requests a way to edit Mendix projects with mxcli while Studio Pro remains open, eliminating the need to close/reopen Studio Pro for each develop‑verify cycle.

Checklist for feature request

Required info	Present?	Details
Use case – why the feature is needed / problem it solves	✅	Describes the cumbersome close‑SP → run mxcli → reopen SP workflow.
Proposed syntax or behavior (if applicable)	❌	No specific CLI syntax, flags, or expected behavior described.
Mendix version relevance (if version‑specific)	❌	No mention of which Mendix versions the feature should target.

Polite request for missing information
Hi Miwa, thanks for the detailed description! To help us evaluate and implement this feature, could you please add:

1. Proposed syntax or behavior – e.g., any new mxcli flags, sub‑commands, or expected changes to the workflow (such as “mxcli edit …” or a specific MCP endpoint to call).
2. Mendix version relevance – indicate whether this is needed for all Mendix versions, or only for certain releases (e.g., 10.x and above, or specific MPR v1/v2 considerations).

Once we have those details, we can move forward with the design. Thanks again for bringing this up!

---

Automated triage via OpenRouter — workflow source

[github-actions]

Enhancement Implementation Guide

Completeness Assessment

The issue describes a user-facing requirement (allowing mxcli edits while Studio Pro remains open) but does not specify concrete technical details needed for implementation. The MCP backend proposal (docs/11-proposals/PROPOSAL_mcp_backend.md) is referenced as the solution, but its contents are not provided in the issue. To proceed, we need clarification on:

1. Current MCP backend status: What exactly was completed in "Phase 0" of the MCP backend proposal? Which components are already implemented?
2. Expected mxcli behavior: Should mxcli automatically detect and use the MCP server when available, or require an explicit flag (e.g., --mcp)? What fallback behavior is expected if the MCP server is unreachable?
3. Detection mechanism: How should mxcli identify Studio Pro's MCP server? (e.g., polling http://localhost:7782/mcp, checking for a lock file, or relying on Studio Pro to advertise the endpoint?)
4. Scope of operations: Which mxcli commands/modifications should route through the MCP server? (All write operations? Only specific MDL statements?)
5. Error handling: What specific error codes/messages should mxcli return when the MCP server is unavailable or returns an error?

Without these details, we cannot design a concrete implementation. The issue tracks the user requirement, but the implementation depends entirely on the MCP backend proposal's specifics.

Overlap Check

• No existing overlap: Currently, mxcli cannot modify projects while Studio Pro has them open due to SQLite write locks (both v1 and v2 MPR formats). No existing mxcli feature bypasses this limitation.
• Related but insufficient:
  • mxcli already implements SetMaxOpenConns(1) and PRAGMA busy_timeout=5000 in sdk/mpr/reader.go to reduce lock contention within mxcli itself, but this does not solve cross-process locks with Studio Pro.
  • The mxcli bson dump tool can inspect MPR files without locks (read-only), but writes still require exclusive access.
  • Studio Pro's own MCP server (if running) could theoretically handle mxcli requests, but no mxcli-to-MCP integration exists yet.

Proposed MDL Syntax

Not applicable – This is an architectural/backend change, not an MDL syntax enhancement. No new MDL verbs, clauses, or properties are required. The user experience remains identical: existing MDL commands (e.g., create entity, alter microflow) will work unchanged when mxcli routes writes through the MCP server.

Implementation Roadmap

Conditional on MCP backend proposal details. Steps assume we need to implement the mxcli side of the MCP integration:

1. Define MCP backend interface (mdl/backend/mcp.go):

   • Extend Backend interface (in mdl/backend/backend.go) with MCP-specific methods if needed (e.g., PingMCP() error).
   • Create MCPBackend struct implementing the backend interface via HTTP calls to http://localhost:7782/mcp.

2. Implement MCP client (mdl/backend/mcp/client.go):

   • HTTP client with retry logic, timeouts, and error mapping to mxcli errors.
   • Serialize backend requests (e.g., CreateEntity, UpdateMicroflow) to JSON payloads matching MCP server expectations.
   • Deserialize MCP responses into backend return types.

3. Backend selection logic (cmd/mxcli/init.go or modelsdk.go):

   • Add UseMCP() bool detection: Attempt HTTP GET to localhost:7782/mcp/health (or similar) with short timeout.
   • In OpenForWriting(), if MCP is available, return MCPBackend; else fall back to direct file access (with existing lock warnings).
   • Respect explicit override via --mcp flag (if desired).

4. Update executor to use backend abstraction (Verify compliance):

   • Ensure all executor paths (mdl/executor/*) exclusively use ctx.Backend.* methods (no direct sdk/mpr imports).
   • Confirm new MCP backend implements all required backend methods (e.g., via var _ Backend = (*MCPBackend)(nil)).

5. Configure build/dependencies:

   • Add HTTP client dependency (e.g., github.com/go-resty/resty/v2) if not already used.
   • Update go.mod and vendor dependencies.

BSON Investigation

Not applicable for mxcli-side work – The MCP server (in Studio Pro) handles BSON serialization. mxcli only needs to:

• Understand the MCP request/response format (defined in the MCP backend proposal).
• Verify that MCP server correctly translates mxcli backend calls to BSON writes (Studio Pro's responsibility).
  If implementing MCP server-side (unlikely per issue context):
• Audit sdk/mpr/writer_*.go to identify which BSON structures require serialization.
• Check reference/mendixmodellib/reflection-data/ for storage names and default values.
• Create test MPR in Studio Pro, extract BSON via mx bson dump, and verify round-trip fidelity.

Testing Strategy

1. Unit tests:

   • Test MCPBackend methods with mock HTTP server (e.g., httptest).
   • Verify error handling for timeouts, 5xx responses, and malformed MCP responses.
   • Test backend selection logic (MCP available vs. unavailable).

2. Integration tests:

   • Start Studio Pro with a test MCP server (or mock MCP endpoint).
   • Run mxcli MDL commands (e.g., create entity Test.Entity (Name: string(50))) while Studio Pro is open.
   • Verify changes appear in Studio Pro without restart.
   • Confirm mx check passes on the modified project.
   • Test fallback to direct access when Studio Pro is closed/MCP unavailable.

3. End-to-end validation:

   • Use mxcli test doctype tests against a project with Studio Pro open.
   • Validate no SQLITE_BUSY or lock-related errors occur during writes.
   • Ensure Studio Pro does not crash or show corruption warnings after mxcli edits.

Gotchas & Risks

1. MCP server version skew:

   • Risk: mxcli MCP client incompatible with Studio Pro's MCP server (different Mendix versions).
   • Mitigation: Negotiate protocol version via MCP handshake; return actionable error if mismatched (e.g., "MCP server v10.0 incompatible with mxcli v11.0").

2. Partial failure handling:

   • Risk: MCP server applies some changes then fails (leaving project in inconsistent state).
   • Mitigation: Ensure MCP server uses transactions for all mxcli-backed operations (Studio Pro's responsibility).

3. False MCP detection:

   • Risk: mxcli detects MCP server on localhost:7782 that isn't Studio Pro's (e.g., another service).
   • Mitigation: Validate MCP response contains Mendix-specific headers/JSON structure (e.g., X-Mendix-MCP-Version).

4. Performance overhead:

   • Risk: HTTP round-trips slow down mxcli vs. direct file access.
   • Mitigation: Batch multiple mxcli statements into single MCP requests where possible (e.g., transactional MDL scripts).

5. Lock escalation:

   • Risk: Studio Pro holds long-lived read locks during mxcli writes (causing timeouts).
   • Mitigation: Configure mxcli MCP client with conservative timeouts; surface Studio Pro-side lock errors clearly to user.

6. Security boundaries:

   • Risk: MCP server exposed

---

Automated guide via OpenRouter — workflow source

[peterjumpnl]

Would be really happy if this is implemented! Any idea about progress?