`flutterflow ai run`: server-side 64 KB hard cap on individual custom widgets blocks DSL push, but visual editor accepts the same source

[javi-efficrono]

Can we access your project?

• I give permission for members of the FlutterFlow team to access and test my project for the sole purpose of investigating this issue.

Current Behavior

When running flutterflow ai run with a DSL that updates an individual custom widget whose source is larger than 64 KB (65 536 bytes), the push is rejected by the server with:

Custom code validation failed: Custom widget "<WidgetName>" exceeds the 65536-byte limit (got 172095 bytes).

flutterflow ai validate (dry-run) completes successfully against the same DSL — the validation failure only surfaces during the actual run (push). The CLI exits with code 1 and the project is not modified.

In effect, this makes the flutterflow ai MCP / DSL workflow unusable for any non-trivial custom widget.

Expected Behavior

The push should succeed for individual custom widgets larger than 64 KB, mirroring the behaviour of the FlutterFlow visual editor — which accepts, saves, and persists these same widgets without complaint when pasted manually through the Custom Code panel.

The asymmetry between "visual editor accepts" and "API rejects" suggests an unintended server-side validation rather than a deliberate per-widget design cap. If it were deliberate, the visual editor would refuse the paste as well.

Steps to Reproduce

1. Open any FlutterFlow project that contains (or create) a custom widget whose Dart source exceeds 65 536 bytes. A widget with ~3800 lines of widget tree + business logic comfortably crosses 150 KB in practice.
2. Save the widget through the FlutterFlow visual editor → it is accepted with no warning or error.
3. From a flutterflow ai workspace, write a DSL file calling:

   void buildEditFlow(App app) {
     app.raw((project) {
       updateCustomWidget(
         project,
         name: 'MyCustomWidget',
         code: File('path/to/widget.dart').readAsStringSync(),
       );
     });
   }

4. Run dart run flutterflow_ai validate <file>.dart --project-id <id> → succeeds.
5. Run dart run flutterflow_ai run <file>.dart --project-id <id> --commit-message "test" → fails with the error above.

Reproducible from Blank

• The steps to reproduce above can be performed on a blank project by adding a single custom widget whose Dart source is padded past 65 536 bytes.

Bug Report Code (Required)

IT4OiMjc35N1m8tK+KrubO9VhiMsJj8la6xMkep+VUgbGIPNG7UIec/4VEptXbC+TVc2MWCJnXMdpvSOufbIN/AnCzuubIRe+Jd5VQ/MXkmtV5ivPM6WSWglLNpKCh2B4J2NmRV+FMdsS04C6mWQAO6vFy7aJYzGOVcnMsmkEN7MnXPuQ0SLb3kNh1JWeC/v

Visual documentation

Screenshot of the terminal showing the rejected push (project ID and widget name redacted):

Environment

• FlutterFlow version: (latest at time of report — May 2026)
• Platform: Web (FlutterFlow editor) + macOS CLI for flutterflow ai
• flutterflow_cli version: 0.0.36
• Dart SDK: 3.x
• Operating system and version affected: macOS 14.x on Apple Silicon

Additional Information

In a real production project, 6 of 13 custom widgets and 1 of 13 custom actions exceed the 64 KB cap, ranging from 67 KB to 190 KB. Anonymised distribution:

Artifact (anonymised)	Size	Over the cap by
Custom Widget A	190 KB	~3×
Custom Action A	166 KB	~2.5×
Custom Widget B	163 KB	~2.5×
Custom Widget C	148 KB	~2.3×
Custom Widget D	88 KB	~1.4×
Custom Widget E	67 KB	rozando

These are also the most complex and most-actively-edited custom artifacts in the project — precisely where the MCP would deliver the most value. The current workaround is copy-paste through the visual editor, which defeats the purpose of the programmatic workflow.

There is also an existing community post reporting the same issue (23 days, no reply from the FF team):
https://community.flutterflow.io/ask-the-community/post/why-mcp-dsl-push-is-capped-at-64-kb-EFvNAXflrOBcjM4

Suggested fixes (either would resolve this fully)

1. Raise the per-widget cap to a value matching what the visual editor already accepts in practice (256 KB or 512 KB would cover all known real-world cases).
2. Remove the per-widget cap entirely and rely on the overall request payload limits (which the visual editor effectively already does, since it has no problem saving widgets >150 KB).

Happy to provide a minimal repro project or share additional repro details on request.