Can we access your project?
Current Behavior
The AI Agent cannot start a session at all on Desktop 7.0.70. Every conversation fails at launch, before a single prompt is processed. There is no degraded mode, no retry that succeeds, and no user-side workaround.
There is also currently no obtainable version to fall back to:
Selecting Claude Code and sending any prompt produces:
[acp] starting claude ACP client
[acp] ERROR: JsonRpcRequestException(-32603, Internal error)
[agent.stream] ERROR: category=parse chars=47
Root cause
FlutterFlow launches the Claude Code CLI with an Agent Client Protocol command-line flag that no published version of the Claude Code CLI accepts. The CLI rejects the flag, prints a plain-text error where the ACP client expects a JSON-RPC frame, and exits.
Note the elapsed time in the log: 2 milliseconds. That is far too short for the CLI to have started, let alone negotiated a protocol. The failure is at process launch, before any MCP involvement.
category=parse chars=47 is the CLI's own error text. The unknown-option message has a fixed shape whose length is always 24 + len(FLAG):
| Flag passed |
Flag length |
Output length |
--acp |
5 |
29 |
--experimental-acp |
18 |
42 |
| a 23-character flag |
23 |
47 |
So 47 characters means the CLI was passed an unknown 23-character option. For example:
$ claude --agent-client-protocol
error: unknown option '--agent-client-protocol' <- exactly 47 characters
To be precise: the character count proves an unknown 23-character flag, but does not identify which one — --agent-client-protocol and --experimental-acp-mode are both 23 characters. You will know which flag 7.0.70 passes.
No published Claude Code CLI has ACP support
| Claude Code CLI |
agent-client-protocol |
experimental-acp |
acp-mode |
| 2.1.236 |
0 |
0 |
0 |
| 2.1.241 |
0 |
0 |
— |
| 2.1.246 (latest published) |
0 |
0 |
0 |
This is not version skew a user can resolve by updating. There is no released Claude Code CLI that accepts this flag.
Scope — the CLI and MCP layers are both healthy
Only the ACP agent session fails. On the same machine, after the update, all of these ran successfully:
flutterflow ai inspect <project-id> --page <PageName> — returned live page JSONflutterflow ai validate dsl/edit.dart — [OK] compileDslAppflutterflow ai run dsl/edit.dart --project-id <project-id> — pushed successfully, returned a commit id
The flutterflow_ai MCP server is also fine — it completes an initialize handshake, returning serverInfo: {"name":"flutterflow_ai","version":"0.0.40"}.
Possibly related
#7429 reports the same JsonRpcRequestException(-32603) on 7.0.73 / macOS with Codex CLI. If that is the same ACP launch path, this is not Claude-specific, not Windows-specific, and not fixed in 7.0.73.
Expected Behavior
Selecting Claude Code as the AI Agent should start a working session, as it did on the previous desktop version.
Failing that, the launch should fail soft — a capability check with a fallback to the previous launch method — rather than hard-failing with an error that points at the wrong subsystem.
Steps to Reproduce
- Install FlutterFlow Desktop 7.0.70 on Windows.
- Install the Claude Code CLI via npm (
@anthropic-ai/claude-code) — any published version, up to and including 2.1.246.
- Open any project and open the AI Agent.
- Select Claude Code and start a new conversation.
- Send any prompt.
- The agent fails immediately with
JsonRpcRequestException(-32603, Internal error).
Confirm the cause directly from a terminal, independently of FlutterFlow:
claude --agent-client-protocol
error: unknown option '--agent-client-protocol'
Reproducible from Blank
Bug Report Code (Required)
Not applicable — this reproduces on a blank project and is independent of any project's contents. The failure occurs before the agent connects to a project at all.
Visual documentation
FlutterFlow AI Agent diagnostics
app: FlutterFlow 7.0.70 (release)
os: windows 10.0 (Build 26200)
runtime: 3.10.7 (stable) on "windows_x64"
active service: claude
cli.claude: claude.cmd — 2.1.236 (Claude Code)
cli.codex: not found
flutter sdk: managedReady (3.38.6)
workspace: ready (set)
phase: ready
spawn environment:
PATH=\AppData\Roaming\FlutterFlow\flutterflow\flutter\bin;[...];\develop\flutter\bin;[...];~\AppData\Local\FlutterFlow\agent-bin
(PATH trimmed to the two Flutter SDK entries relevant to this report.
Note the bundled 3.10.7 appears FIRST, ahead of the 3.13.0 install.)
[all other environment variables omitted]
[workspace.trust] pre-approved flutterflow_ai MCP server for the workspace
[models.probe] starting /model scrape (pty)
[acp] starting claude ACP client 07:12:03.045607
[acp] ERROR: JsonRpcRequestException(-32603, Internal error) 07:12:03.047610
[agent.stream] ERROR: category=parse chars=47 07:12:03.047610
[acp] starting claude ACP client 07:13:54.863084
[acp] ERROR: JsonRpcRequestException(-32603, Internal error) 07:13:55.050299
[acp] claude could not resume its session — starting fresh
[acp] ERROR: JsonRpcRequestException(-32603, Internal error) 07:13:55.052297
[agent.stream] ERROR: category=parse chars=47 07:13:55.052297
Environment
- FlutterFlow version: Desktop 7.0.70
- Platform: Windows Desktop
- Operating system: Windows 11
- Claude Code CLI: 2.1.236 / 2.1.241 / 2.1.246 (all fail identically)
- Dart: 3.10.7
- Flutter: 3.38.6
Additional Information
I'm blocked on this. The AI Agent is my primary building surface and there is no version I can install where it works.
Two requests beyond the fix itself.
1. Please surface the child process's stderr when an agent launch fails. The most costly part of diagnosing this was that -32603 points at the transport layer, which is healthy, while the CLI's actual message — error: unknown option ... — is discarded. Logging the first N bytes received when a parse fails would turn hours of investigation into seconds. The chars=47 counter already exists; the bytes themselves are what is needed.
2. A latent second issue, currently masked because the agent never starts.
The spawn environment places the bundled Dart 3.10.7 first on PATH, and .mcp.json launches the MCP server with a bare dart command. But the MCP server's own lockfile requires Dart 3.11+:
.flutterflow/sdk/flutterflow_ai/mcp/pubspec.lock → dart: ">=3.11.0 <4.0.0", pinning dart_style 3.1.12 and analyzer 14.1.0.flutterflow/sdk/flutterflow_ai/pubspec.lock (one directory up) → dart: ">=3.10.0 <4.0.0"
Those two lockfiles are inconsistent with each other, and the MCP server's requirement is not satisfied by the interpreter FlutterFlow itself places first on PATH. Running the server under the bundled 3.10.7 fails to compile:
Error: The language version 3.11 specified for the package 'dart_style' is too high.
The highest supported language version is 3.10.
Under Dart 3.13.0 the server starts cleanly.
Suggested fix: either pin .mcp.json's command to an absolute Dart 3.11+ interpreter rather than a bare dart, or align the MCP lockfile with the Dart version shipped and placed first on PATH.
Can we access your project?
Current Behavior
The AI Agent cannot start a session at all on Desktop 7.0.70. Every conversation fails at launch, before a single prompt is processed. There is no degraded mode, no retry that succeeds, and no user-side workaround.
There is also currently no obtainable version to fall back to:
JsonRpcRequestException(-32603)with Codex on macOSSelecting Claude Code and sending any prompt produces:
[acp] starting claude ACP client
[acp] ERROR: JsonRpcRequestException(-32603, Internal error)
[agent.stream] ERROR: category=parse chars=47
Root cause
FlutterFlow launches the Claude Code CLI with an Agent Client Protocol command-line flag that no published version of the Claude Code CLI accepts. The CLI rejects the flag, prints a plain-text error where the ACP client expects a JSON-RPC frame, and exits.
Note the elapsed time in the log: 2 milliseconds. That is far too short for the CLI to have started, let alone negotiated a protocol. The failure is at process launch, before any MCP involvement.
category=parse chars=47is the CLI's own error text. The unknown-option message has a fixed shape whose length is always24 + len(FLAG):--acp--experimental-acpSo 47 characters means the CLI was passed an unknown 23-character option. For example:
$ claude --agent-client-protocol
error: unknown option '--agent-client-protocol' <- exactly 47 characters
To be precise: the character count proves an unknown 23-character flag, but does not identify which one —
--agent-client-protocoland--experimental-acp-modeare both 23 characters. You will know which flag 7.0.70 passes.No published Claude Code CLI has ACP support
agent-client-protocolexperimental-acpacp-modeThis is not version skew a user can resolve by updating. There is no released Claude Code CLI that accepts this flag.
Scope — the CLI and MCP layers are both healthy
Only the ACP agent session fails. On the same machine, after the update, all of these ran successfully:
flutterflow ai inspect <project-id> --page <PageName>— returned live page JSONflutterflow ai validate dsl/edit.dart—[OK] compileDslAppflutterflow ai run dsl/edit.dart --project-id <project-id>— pushed successfully, returned a commit idThe
flutterflow_aiMCP server is also fine — it completes aninitializehandshake, returningserverInfo: {"name":"flutterflow_ai","version":"0.0.40"}.Possibly related
#7429 reports the same
JsonRpcRequestException(-32603)on 7.0.73 / macOS with Codex CLI. If that is the same ACP launch path, this is not Claude-specific, not Windows-specific, and not fixed in 7.0.73.Expected Behavior
Selecting Claude Code as the AI Agent should start a working session, as it did on the previous desktop version.
Failing that, the launch should fail soft — a capability check with a fallback to the previous launch method — rather than hard-failing with an error that points at the wrong subsystem.
Steps to Reproduce
@anthropic-ai/claude-code) — any published version, up to and including 2.1.246.JsonRpcRequestException(-32603, Internal error).Confirm the cause directly from a terminal, independently of FlutterFlow:
Reproducible from Blank
Bug Report Code (Required)
Not applicable — this reproduces on a blank project and is independent of any project's contents. The failure occurs before the agent connects to a project at all.
Visual documentation
FlutterFlow AI Agent diagnostics
app: FlutterFlow 7.0.70 (release)
os: windows 10.0 (Build 26200)
runtime: 3.10.7 (stable) on "windows_x64"
active service: claude
cli.claude: claude.cmd — 2.1.236 (Claude Code)
cli.codex: not found
flutter sdk: managedReady (3.38.6)
workspace: ready (set)
phase: ready
spawn environment:
PATH=
\AppData\Roaming\FlutterFlow\flutterflow\flutter\bin;[...];\develop\flutter\bin;[...];~\AppData\Local\FlutterFlow\agent-bin(PATH trimmed to the two Flutter SDK entries relevant to this report.
Note the bundled 3.10.7 appears FIRST, ahead of the 3.13.0 install.)
[all other environment variables omitted]
[workspace.trust] pre-approved flutterflow_ai MCP server for the workspace
[models.probe] starting /model scrape (pty)
[acp] starting claude ACP client 07:12:03.045607
[acp] ERROR: JsonRpcRequestException(-32603, Internal error) 07:12:03.047610
[agent.stream] ERROR: category=parse chars=47 07:12:03.047610
[acp] starting claude ACP client 07:13:54.863084
[acp] ERROR: JsonRpcRequestException(-32603, Internal error) 07:13:55.050299
[acp] claude could not resume its session — starting fresh
[acp] ERROR: JsonRpcRequestException(-32603, Internal error) 07:13:55.052297
[agent.stream] ERROR: category=parse chars=47 07:13:55.052297
Environment
Additional Information
I'm blocked on this. The AI Agent is my primary building surface and there is no version I can install where it works.
Two requests beyond the fix itself.
1. Please surface the child process's stderr when an agent launch fails. The most costly part of diagnosing this was that
-32603points at the transport layer, which is healthy, while the CLI's actual message —error: unknown option ...— is discarded. Logging the first N bytes received when a parse fails would turn hours of investigation into seconds. Thechars=47counter already exists; the bytes themselves are what is needed.2. A latent second issue, currently masked because the agent never starts.
The spawn environment places the bundled Dart 3.10.7 first on PATH, and
.mcp.jsonlaunches the MCP server with a baredartcommand. But the MCP server's own lockfile requires Dart 3.11+:.flutterflow/sdk/flutterflow_ai/mcp/pubspec.lock→dart: ">=3.11.0 <4.0.0", pinningdart_style 3.1.12andanalyzer 14.1.0.flutterflow/sdk/flutterflow_ai/pubspec.lock(one directory up) →dart: ">=3.10.0 <4.0.0"Those two lockfiles are inconsistent with each other, and the MCP server's requirement is not satisfied by the interpreter FlutterFlow itself places first on PATH. Running the server under the bundled 3.10.7 fails to compile:
Error: The language version 3.11 specified for the package 'dart_style' is too high.
The highest supported language version is 3.10.
Under Dart 3.13.0 the server starts cleanly.
Suggested fix: either pin
.mcp.json'scommandto an absolute Dart 3.11+ interpreter rather than a baredart, or align the MCP lockfile with the Dart version shipped and placed first on PATH.