WAIT: Global-class `selectors` created through MCP can render on the frontend but remain invisible in the Bricks Builder UI

Bugs
1

Environment

  • Bricks: 2.4-beta3
  • Bricks Abilities contract: 2.0.0
  • MCP Adapter: 0.6.1
  • WordPress: 7.0.4

Summary

The MCP abilities for creating and updating global classes expose a writable selectors array for descendant, pseudo-element, and other chained selectors.

Rules saved through this field render correctly on the frontend, but they are not shown in the global class’s Style panel or Class Manager. This allows an MCP client to create functional CSS that a Bricks user cannot discover or edit through the builder.

For editor-visible chained rules, the working representation is the global class’s Custom CSS field:

%root% .employees__group-title {
  color: var(--primary);
}

Through MCP, this belongs in settings._cssCustom rather than the global class’s selectors array.

Current MCP guidance

  • bricks/create-global-class describes selectors as “Custom CSS sub-selectors” and provides &::before as an example.
  • bricks/batch-create-global-classes provides the same guidance.
  • bricks/update-global-class accepts a complete replacement selectors array.
  • The resolved global-class schema says selector entries allow settings to be scoped to arbitrary CSS selectors.
  • The schema describes label as an optional display label in the builder UI.
  • Neither the abilities nor the installed Bricks skills warn that these selector records may be invisible in the builder.
  • The installed skills do not document %root% for global-class Custom CSS.

Steps to reproduce

  1. Create or update a global class through MCP with a selector record similar to:

    {
  "name": "selector-test",
  "selectors": [
    {
      "selector": "& .selector-test__child",
      "label": "Child",
      "settings": {
        "_typography": {
          "color": {
            "raw": "var(--primary)"
          }
        }
      }
    }
  ]
}

  2. Apply the global class to an element containing .selector-test__child.

  3. Confirm that the resulting CSS affects the frontend.

  4. Open the global class in the Bricks Style panel and Class Manager.

  5. Observe that the descendant rule cannot be found or edited.

  6. Move the rule to settings._cssCustom, using %root% in the builder representation.

  7. Confirm that it is now visible under Style → CSS → Custom CSS.

Actual result

The rule renders on the frontend, but the Bricks user cannot find or edit it in the normal builder interface.

Expected result

One of the following should apply:

  1. Selector records are exposed and editable in the Bricks UI; or
  2. MCP abilities and skills clearly state that selectors must not be used for editor-visible global-class rules and direct clients to settings._cssCustom with %root%.

Impact

This creates hidden styling state:

  • Users cannot determine where an active rule originates.
  • Future builder edits can conflict with rules the editor does not expose.
  • Class audits incorrectly appear clean.
  • Repair requires inspecting raw MCP or global-class data.