Generated banner for Wix Harmony Editor
Generated logo for Wix Harmony Editor

Wix Harmony Editor

WixOfficialPublished by Wix

  • Skill
  • Tool integration
  • Software development
  • MIT
  • Low risk
  • Has scripts

From the author

Edit Wix Harmony sites through an authenticated Harmony editor using Playwright over a local Chrome CDP session. Use for inspecting, changing, saving, and verifying Harmony editor components and layouts, and for copying an existing website's pages into Harmony exactly (see COPY-SITE.md); do not use for Wix Studio, the classic Editor, Dashboard data, or publishing without explicit approval.
— the description by Wix

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The wix-harmony-editor skill provides a framework for programmatically interacting with the Wix Harmony editor. It uses a local Chrome instance launched via CDP to allow an AI agent to inspect, modify, and verify website components and layouts. The skill includes a suite of scripts for tasks such as copying site pages, managing media, and performing responsive layout adjustments, while adhering to strict safety guidelines regarding site publication and dashboard data access.

What it does

  • Connects to an authenticated Wix Harmony editor session via Playwright and CDP.
  • Provides access to the internal editor API for component inspection and layout manipulation.
  • Supports automated site migration and page copying workflows.
  • Includes utility scripts for media management, preview comparisons, and responsive design verification.
  • Enforces safety protocols to prevent unauthorized site publishing or dashboard data modification.

When to use it

  • When you need to perform bulk updates or complex layout adjustments within the Wix Harmony editor.
  • When migrating content from an existing website into a new Wix Harmony site.
  • When verifying responsive design behavior across different viewport widths.
  • When you need to programmatically inspect component properties or styles that are not easily accessible via the standard UI.

Advantages

  • Enables precise, repeatable programmatic control over editor components.
  • Reduces manual effort for repetitive site-building or migration tasks.
  • Provides tools for validating responsive scaling and layout integrity.
  • Maintains a clear separation between front-end editing and sensitive dashboard data.

Usage examples

“Inspect the layout properties of the hero section with ID 'hero-123' in the current editor.”
The agent uses the editor API to fetch and return the layout, composition, and measured dimensions of the specified component.
“Update the height of the component 'frame-456' to 500px.”
The agent executes a script to set the component size and verifies the change by reading back the updated layout state.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/wix/wix-harmony-editor/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip wix-harmony-editor.zip -d .agents/skills

Documentation by Wix

Wix Harmony editor

Work through the Wix Harmony editor, not the published site. Use the local Chrome launcher and Playwright; the standard in-app browser may not expose the isolated Chrome CDP session.

This file is how to connect to the editor and work in it. Copying an existing site's page into Harmony has its own rules: read COPY-SITE.md before starting a copy.

Order for a migration: create the site, then bring the data (store, bookings, blog and other app data, public and/or private), then build the front end here. Do not start the editor for a store or other app-backed site before its data is in, unless the user asks and approves (COPY-SITE.md, "Order").

Safety and scope

  • Treat the editor as a persistent external system. Inspect before writing.

  • Obtain clear user authorization immediately before a persistent change unless the request already explicitly authorizes that exact change. State the component and intended effect.

  • Never publish unless the user explicitly asks. Saving a draft is not publishing.

  • Work only on visible front-end editor content. Dashboard data (Stores, Bookings, contacts, orders, coupons, members, blog posts, or settings) is out of scope. Site media and fonts that the page displays are front-end content and in scope.

  • The launcher uses a separate Chrome profile. Never use, copy, or inspect the user's normal Chrome profile.

  • Do not expose cookies, local storage, headers, session data, or CDP WebSocket URLs. Use only the local http://127.0.0.1:9333 endpoint launched for this task.

  • If the sandbox blocks connectOverCDP with EPERM, request elevation specifically for the local loopback connection. Do not use a remote host, a different port, or a workaround that exposes the debugger.

Launch and authenticate

Run the bundled launcher with the Wix editor URL:

skills/wix-harmony-editor/scripts/launch.sh 'https://example.editor.wix.com/edit/...'

It starts a headed Chrome instance with an isolated, private profile and a loopback-only CDP port. If Wix shows a sign-in page, let the user authenticate in that browser. Never ask for or enter credentials yourself.

The launcher is intentionally quiet about CDP internals. It reports only whether local Chrome is reachable.

The first launch usually lands on users.wix.com/signin. Tell the user to sign in in that window (the account that owns the site), then poll until the editor tab exists and window.repluggableAppDebug is defined. Do not treat the sign-in page as an error.

Attach with Playwright

Confirm the expected editor is open before doing anything else:

node --input-type=module -e "
import { chromium } from 'playwright';
const browser = await chromium.connectOverCDP('http://127.0.0.1:9333');
const pages = browser.contexts().flatMap(context => context.pages());
console.log(await Promise.all(pages.map(async page => ({ url: page.url(), title: await page.title() }))));
await browser.close();
"

In a Playwright script, resolve the editor page mechanically:

const page = browser.contexts()
  .flatMap(context => context.pages())
  .find(page => page.url().includes('editor.wix.com/edit/'));

if (!page) throw new Error('No authenticated Wix Harmony editor page is open.');

browser.close() detaches Playwright; it does not close the launched Chrome instance.

Initialize and use the Harmony API

All API code runs in page.evaluate:

const api = await repluggableAppDebug.host.getAPI({
  name: 'RunEditorLLMCodeToolAPI',
  public: true,
  layer: 'DATA_SERVICE',
});

Execute editor code with the required editor context:

await api.execute(
  { code: 'return await editorLLMApis.catalog.list();' },
  { biParams: {} },
);

The { biParams: {} } second argument is required in this workflow. Omitting it produces Cannot read properties of undefined (reading 'biParams'); that error changed nothing in the observed case, but do not use failed calls to discover write signatures.

Discover before acting
  1. Start with editorLLMApis.catalog.list() for namespace orientation.

  2. Read documentation only for namespaces needed by the task, in one documentation-only call:

    return await editorLLMApis.catalog.describe({
      namespaces: ['pages', 'components', 'layout', 'breakpoints', 'appearance', 'site'],
    });

    describe has a response budget. A namespace that does not fit comes back as [NOT RETURNED …] or [Truncated …]; fetch that one alone with catalog.describe({ namespaces: ['<name>'] }). components, richText, media, layout and appearance each need their own call. Save the docs to files and read them from there instead of re-fetching.

  3. Never introspect undocumented API objects or guess a write method's arguments.

  4. Open/focus the correct page before reads, because component reads resolve against the focused page.

  5. Use IDs, element paths, units, tokens, and schemas returned by live reads—never assumed values.

  6. After every write, do a fresh read of the normalized, user-visible result. A write echo alone is not verification.

Common namespaces: pages (focus the page), components (find and inspect), layout (measure and resize), breakpoints (desktop/mobile view), appearance (borders/backgrounds), and site (save/publish status).

Execution pattern

const result = await page.evaluate(async () => {
  const api = await repluggableAppDebug.host.getAPI({
    name: 'RunEditorLLMCodeToolAPI',
    public: true,
    layer: 'DATA_SERVICE',
  });

  return api.execute({
    code: `
      const focused = await editorLLMApis.pages.getFocused();
      return { focused };
    `,
  }, { biParams: {} });
});

Check the returned action result for errors before taking the next step.

A failed snippet reports completedCalls with the ids it created. Those writes persist: continue from the failed call reusing those ids, never re-run the whole snippet.

Bundled scripts

Run from this skill's directory. They import playwright, resolved from the working tree.

ScriptUse
scripts/launch.sh <editorUrl>Start the isolated, headed Chrome on loopback CDP 9333.
node scripts/copy/lint-api.mjs --capabilities caps.json [--snippet] <file…>Check every A.<ns>.<method>( call against the editor's real method list (recorded by snapshot-capabilities.mjs) before it is sent.
node scripts/copy/editor-run.mjs <snippet.js> [--site <metaSiteId>] [--capabilities caps.json]Run one editor-API snippet kept in a file; prints result or the failure summary. Lints the snippet when --capabilities / HARMONY_CAPABILITIES is set. Prefer this over inline -e code (no quoting bugs, replayable record).
node scripts/copy/upload-media-manager.mjs <sectionId> <file…>Upload local files to the site's Media Manager through the editor's own dialog.
node scripts/copy/compare-preview.mjs <sourceUrl> <outDir>Editor Preview at true canvas width vs the source, plus stacked zoom crops.
node scripts/copy/preview-widths.mjs <sourceUrl> <outDir> --widths … [--scale-check <sectionId>]Preview at exact widths (slider) vs the source, plus a check that every element scales with the width.
node scripts/copy/build-description.mjs, check-description.mjs, deploy-description.mjsPage description → local compliance/overlap/render check → one-pass deploy with read-back; see COPY-SITE.md.
node scripts/copy/export-page.mjs, snapshot-capabilities.mjs, import-media.mjsRecipes from a copied page, the editor's accepted schemas, public images imported by URL.
node scripts/copy/mobile-stage.mjs hide|bg-opacity …The two mobile-only changes with no API: Hide, and the background image opacity.
node scripts/copy/mirror-site.mjs, serve-mirror.mjs, check-mirror.mjsOffline copy of the source site, served locally and pixel-checked against live; see COPY-SITE.md step 0.
node scripts/copy/measure-source.mjs, node scripts/copy/render-plate.mjsSite copying; see COPY-SITE.md.
Editor behaviors learned live

These hold for the Harmony editor API as observed; check the live read when one disagrees.

  • Global header and footer. sections.list returns the page's header/footer as a RefComponent (role: header|footer); background and layout writes on that id are refused. Target its masterId (on masterPage) for setContainerBackground, components.add and layout.*.

  • Text inside the global header/footer refuses the text-panel actions (richText.setColor, setLink, setAlign, setFontFamily: "cannot be selected"). Style it with appearance.setStyles on the text component (color, textAlign, fontFamily, fontSize, lineHeight, …). For a link, put an inline <a href> in richText.setText HTML (it survives), or use a Button with links.set.

  • Header/footer height has two parts. Each has an internal container (wixSystemElements.InternalContainer, child of the master; find it in the stage DOM as [class*="internalContainerRoot"] under #<pageHeaderOrFooterId>). The background layer and the visible height follow the internal container, not the header/footer box. layout.setSize both to the same height; the background may update only after the next setContainerBackground. The internal container's grid rows are [minContent, 1fr]: a second text block that stacks under the first can be clipped. Merge lines into one rich text with <br> instead.

  • Freeform layout is a grid of rows. A section places each child in a grid row with margins. layout.setComposition resolves all of a container's children as one set and rejects the whole arrangement if any two boxes overlap or leave the container, sometimes silently, leaving the auto-placed positions. Even sub-pixel overlaps of touching text boxes count. Send one complete, overlap-free arrangement per container, read getComposition back, and fix the inputs. Do not correct drift with layout.move after a composition: it re-flows the rows and makes it worse.

  • Content-sized boxes. Rich text height is lines × line-height. A single-line text whose box is exactly as wide as its words can wrap on a sub-pixel font difference and push everything below it down. Give single-line boxes ≥10 px of slack (left-aligned, so the text start does not move). Buttons grow to fit a wrapped label; setSize height on a content-sized axis is only a minimum.

  • Sizes scale with the viewport (spx). Font sizes, margins and box sizes written in px are stored as spx (scaled to the 1280 reference width), so a desktop layout grows and shrinks proportionally between the desktop breakpoints. Anything that stays a real px breaks that proportion: a lineHeight: '42px' on text, a px line-height inside a button label, a px section height. Write line heights as em ratios ('1.4em'), write fontSize and lineHeight in the same setStyles call (writing only lineHeight can rescale the stored font size), and read both back. Prove it with preview-widths.mjs --scale-check: every child must scale by w2/w1.

  • Auto-height sections. A section added with sections.add has height: auto, set by its content rows, so it scales with the page. A section that came with the template, or one whose height was set with layout.setSize, has a fixed px height that does not scale. For a copied page, use a new auto-height section and move the content into it with components.canReparent + components.reparent (ids and styles are kept).

  • Desktop vs mobile views. The mobile view (below 1024 px) shows the same components. Per view through the API, in the mobile view: layout.setComposition positions, widths and the section box.height. Shared (a write in mobile view changes desktop too): image heights (send none on mobile, the ratio derives them), layout.setSize, appearance.setStyles, appearance.setContainerBackground. Stage-only, per view: Hide and the background image opacity (scripts/copy/mobile-stage.mjs).

  • Classic scrollbars shrink the canvas. With an always-visible OS scrollbar the stage loses 15 px: a desktop section reads 1265 instead of 1280, a mobile one 375 instead of 390, and every composition then lands off (a deploy reports dozens of differences; switching the OS setting between a trackpad and a mouse does this). The copy scripts call hide-scrollbars.mjs (Emulation.setScrollbarsHidden, which lasts only while their CDP session is attached). If you drive the editor another way, check layout.getComposition on a section: width must be 1280/390.

  • Compositions are anchored, not absolute. Each child is kept relative to the one above it. When a child ends up shorter or taller than the box sent (a new text that reflows, an image height off its ratio, a Button below its label height), everything after it moves. Send the heights the engine will compute and re-send the set until getComposition matches (deploy-description.mjs does both).

  • Rich text. setText keeps inline <span style="color|font-weight|font-family|font-size"> and <a href> as sent (a px font size in a span does not scale: use em). links.set on a rich text rewrites it: the root becomes <h1> with an underline span. Keep text links inline. A plain single line goes through injectText.

  • Buttons size to their label. A set height is a minimum; a tall transparent click area gets its height from the label lineHeight in em.

  • Results over ~50 KB are truncated ("[Truncated: … chars]" in place of the value). Read in batches, or compare inside the snippet and return only the differences.

  • pages.add creates an empty placeholder section (shouldReuse: true); a deploy that adds its own section removes it.

  • Hide is per view, and only from mobile. Right-click a component or section on the mobile stage → Hide hides it on mobile only. Desktop has no Hide (it is the base view), so content can be hidden from mobile but never from desktop. Un-hide in the Layers panel → Hidden on mobile → the eye button on the row ([data-hook="layers-item@DESKTOP--<id>"] button).

  • Global header/footer are hard to make responsive. They are a single row ([minContent, 1fr] grid) and their background does not follow the page content. For an exact copy, collapse them (header, footer and their internal containers set to 1 px, background transparent) and build the nav and footer inside the page's own section, where they scale with everything else.

  • Media. media.uploadFiles accepts only temporary wixmp chat URLs. Import public web images from a copied page with scripts/copy/import-media.mjs, which downloads each one itself (global-unicast destinations only, at most 10 MB, six at a time, once per distinct URL) and uploads the bytes through POST https://www.wixapis.com/site-media/v1/files/generate-upload-url (site token, header wix-site-id); never pass an untrusted page's URL to files/import, which makes Wix fetch it. Then read the uri with media.searchSiteFiles. Upload local files with scripts/copy/upload-media-manager.mjs. Image values for content.set are { uri, name, alt, width, height }; add displayMode: 'fit' to show the whole image.

  • Fonts. Only the editor's catalog and the site's uploaded fonts render. Importing a .ttf through the media API creates a FONT file that is not registered. Register fonts through the editor: select any text, open the font dropdown in the text toolbar, click Upload fonts, then feed input[type=file][accept*=".ttf"] with setInputFiles. Afterwards fonts.resolve('<Name>') refuses but suggests the uploaded family (wfont_<x>_<id>,wf_<id25>,orig_<name>): use that full string as fontFamily.

  • Buttons as text links. A Button with transparent background, zero borders/padding and a styled label element is the reliable linked text in global header/footer. Theme button looks are saved styles: restyle one button locally, then themeComponents.updateFromComponent({ kind: 'button', styleId: 'button-primary', … }).

  • Pinned elements. layout.pinToScreen({ position: 'center-bottom', offsetPx }) pins a floating button and moves it to the page (out of the section). A pinned component cannot be resized: set its size first, or unpin, resize and pin again.

  • Tokens expire. A CLI site token (npx @wix/cli@latest token --site <id>) stops working during a long session (REST calls start returning 403). Re-mint and retry once before diagnosing anything else.

  • True-width Preview. The Preview frame defaults to 1280 px whatever the window size. Its width slider ([data-hook="slider-handle"], aria-valuenow, range 390 to the window width minus 84) is only rendered while the window is at least ~1300 px wide. Click the slider track near the target, then use the arrow keys for the exact width (preview-widths.mjs does this). A free site adds a 44 px "Upgrade" banner above the page. The editor stage is zoomed (Fit (60–110%)), so stage screenshots are not a pixel reference.

  • Watch the published state. site.getStatus().isPublished became true during scripted UI work on this site, cause unknown. Read it before and after UI automation, never click by raw coordinates in the top bar (Publish is there), and report a change to the user instead of quietly reverting it.

Example: make a hero frame responsive

When a hero frame scales in width but its text overflows at wide desktop sizes, find visible title text, inspect its ancestors, and identify the bordered frame container:

const title = await editorLLMApis.components.find({
  textContains: 'Hero title',
  limit: 20,
});

const inspection = await editorLLMApis.components.inspect({
  componentId: title.components[0].id,
  aspects: ['layout', 'styles'],
  neighbourhood: true,
});

Read the frame's declared layout and composition. A typical problem is a percentage width paired with fixed pixel height while the text uses spx sizing:

const frameId = 'REPLACE_WITH_FRAME_COMPONENT_ID';
const layout = await editorLLMApis.layout.get({ componentId: frameId });
const composition = await editorLLMApis.layout.getComposition({ componentId: frameId });
const measured = await editorLLMApis.layout.measure({ componentId: frameId });
return { layout, composition, measured };

For a frame declared as height: { value: 536, unit: 'px' }, the responsive repair is normally to preserve the value and use Wix scaled pixels. After authorization:

const updated = await editorLLMApis.layout.setSize({
  componentId: frameId,
  height: 536, // plain pixels: the component keeps its own unit (spx stays spx) and the value is recomputed
});

const verifiedLayout = await editorLLMApis.layout.get({ componentId: frameId });
const status = await editorLLMApis.site.getStatus();
return { updated, verifiedLayout, status };

Verify that the stored height is { type: 'spx', value: 536 }, that the editor reports a successful save state, and that the site remains unpublished unless publication was explicitly requested.

Files

scripts/launch.sh

#!/bin/bash
# Launch a separate, headed Chrome profile for a Wix Harmony editor session.
# The Chrome DevTools endpoint is loopback-only and is never printed.
#
# Cross-platform: macOS, Linux (including headless boxes with no physical
# display), WSL, and Windows Git Bash/MSYS are detected and a usable
# Chrome/Chromium binary is located for each. Nothing here is ever
# substituted silently: if no browser can be found, the script fails with
# an actionable message naming what to install.
#
# Headless Linux note: Wix Harmony intentionally requires a HEADED browser
# (never --headless) so a human can interact with a Wix sign-in page if one
# appears. A machine with no physical monitor can still run headed Chrome
# against a virtual framebuffer (Xvfb) - this script will start one
# automatically on Linux if $DISPLAY isn't already set and Xvfb is
# installed. Xvfb itself is a prerequisite install (see the error message
# below); this script does not silently `sudo apt-get install` anything on
# your behalf.
#
# If Wix shows a sign-in page while running under a virtual display, you
# need some way to actually see and interact with it. Options, from
# simplest to most complete:
#   - Take a screenshot from Playwright (page.screenshot()) to see the
#     current page - good enough to tell what state the editor is in, but
#     not interactive.
#   - Run a lightweight VNC server against the same DISPLAY, e.g.:
#       x11vnc -display :99 -localhost -nopw
#     then forward the VNC port (default 5900) to a machine with a VNC
#     client. This gives full interactive mouse/keyboard control, but you
#     are responsible for setting up that port forward for your sandbox.
set -euo pipefail

SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
PORT="${PW_PORT:-9333}"
PROFILE="${WIX_HARMONY_PROFILE_DIR:-${TMPDIR:-/tmp}/wix-harmony-editor-profile}"
EDITOR_URL="${1:-about:blank}"

umask 077
mkdir -p "$PROFILE"
chmod 700 "$PROFILE"

CHROME_PID_FILE="${PROFILE}/chrome.pid"

# True when the process recorded at launch is still alive and was started with THIS profile and
# port, so a responding CDP endpoint is provably the Chrome this script launched for this profile.
launched_chrome_is_ours() {
  local pid cmd
  [[ -f "$CHROME_PID_FILE" ]] || return 1
  pid="$(tr -d '[:space:]' <"$CHROME_PID_FILE" 2>/dev/null || true)"
  [[ "$pid" =~ ^[0-9]+$ ]] || return 1
  kill -0 "$pid" 2>/dev/null || return 1
  cmd="$(ps -p "$pid" -o args= 2>/dev/null || true)"
  [[ "$cmd" == *"--user-data-dir=${PROFILE}"* && "$cmd" == *"--remote-debugging-port=${PORT}"* ]]
}

# If a Wix Harmony Chrome is already up on this port, nothing else to do. Any other responding
# CDP endpoint (another Chrome, a Playwright browser) is NOT reused: the copy tools would drive the
# wrong browser, profile or site.
if curl -fsS -m 2 "http://127.0.0.1:${PORT}/json/version" >/dev/null 2>&1; then
  if launched_chrome_is_ours; then
    echo "Wix Harmony Chrome is already running on local CDP port ${PORT}."
    exit 0
  fi
  echo "Local CDP port ${PORT} is already served by a browser this script did not launch for" >&2
  echo "profile ${PROFILE}. Not reusing it. Stop that browser, or set PW_PORT to a free port" >&2
  echo "(and use the same PW_PORT for every script), then re-run." >&2
  exit 1
fi

# --- OS detection -----------------------------------------------------
detect_os() {
  local uname_s
  uname_s="$(uname -s 2>/dev/null || echo unknown)"
  case "$uname_s" in
    Darwin)
      echo macos
      ;;
    Linux)
      if grep -qi microsoft /proc/version 2>/dev/null; then
        echo wsl
      else
        echo linux
      fi
      ;;
    MINGW*|MSYS*|CYGWIN*)
      echo windows
      ;;
    *)
      echo unknown
      ;;
  esac
}

OS_TYPE="$(detect_os)"

# --- Chrome/Chromium discovery -----------------------------------------
# Prints the resolved binary path on stdout, or nothing if not found.
find_chrome_macos() {
  local candidates=(
    "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"
    "$HOME/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"
    "/Applications/Google Chrome for Testing.app/Contents/MacOS/Google Chrome for Testing"
    "/Applications/Chromium.app/Contents/MacOS/Chromium"
  )
  local c
  for c in "${candidates[@]}"; do
    if [[ -x "$c" ]]; then
      echo "$c"
      return 0
    fi
  done
  return 1
}

# Finds the newest Playwright-managed Chromium build under its cache dir,
# e.g. ~/.cache/ms-playwright/chromium-1234/chrome-linux64/chrome. This is
# the browser `npx playwright install` downloads; it's a reasonable
# fallback on Linux boxes with no system Chrome package installed.
find_chrome_playwright_linux() {
  local pw_dir="${PLAYWRIGHT_BROWSERS_PATH:-$HOME/.cache/ms-playwright}"
  [[ -d "$pw_dir" ]] || return 1
  local newest
  newest="$(find "$pw_dir" -maxdepth 1 -type d -iname 'chromium-*' 2>/dev/null | sort -V | tail -1)"
  [[ -n "$newest" ]] || return 1
  local sub
  for sub in chrome-linux64/chrome chrome-linux/chrome; do
    if [[ -x "$newest/$sub" ]]; then
      echo "$newest/$sub"
      return 0
    fi
  done
  return 1
}

find_chrome_linux() {
  local bin
  for bin in google-chrome google-chrome-stable chromium chromium-browser; do
    if command -v "$bin" >/dev/null 2>&1; then
      command -v "$bin"
      return 0
    fi
  done
  find_chrome_playwright_linux && return 0
  return 1
}

find_chrome_wsl() {
  # Prefer a native Linux Chrome/Chromium installed inside the WSL distro,
  # then fall back to the Windows-side install reachable under /mnt/c.
  find_chrome_linux && return 0
  local candidates=(
    "/mnt/c/Program Files/Google/Chrome/Application/chrome.exe"
    "/mnt/c/Program Files (x86)/Google/Chrome/Application/chrome.exe"
  )
  local c
  for c in "${candidates[@]}"; do
    if [[ -x "$c" ]]; then
      echo "$c"
      return 0
    fi
  done
  return 1
}

find_chrome_windows() {
  local bin
  for bin in chrome.exe chromium.exe; do
    if command -v "$bin" >/dev/null 2>&1; then
      command -v "$bin"
      return 0
    fi
  done
  local candidates=(
    "/c/Program Files/Google/Chrome/Application/chrome.exe"
    "/c/Program Files (x86)/Google/Chrome/Application/chrome.exe"
  )
  local c
  for c in "${candidates[@]}"; do
    if [[ -x "$c" ]]; then
      echo "$c"
      return 0
    fi
  done
  return 1
}

CHROME=""
case "$OS_TYPE" in
  macos)   CHROME="$(find_chrome_macos || true)" ;;
  linux)   CHROME="$(find_chrome_linux || true)" ;;
  wsl)     CHROME="$(find_chrome_wsl || true)" ;;
  windows) CHROME="$(find_chrome_windows || true)" ;;
esac

if [[ -z "$CHROME" ]]; then
  case "$OS_TYPE" in
    macos)
      echo "No Google Chrome or Chromium install was found under /Applications." >&2
      echo "Install Google Chrome (https://www.google.com/chrome/) and retry." >&2
      ;;
    linux)
      echo "No Chrome/Chromium binary was found on PATH (checked: google-chrome," >&2
      echo "google-chrome-stable, chromium, chromium-browser), and no Playwright-managed" >&2
      echo "Chromium was found under \${PLAYWRIGHT_BROWSERS_PATH:-~/.cache/ms-playwright}." >&2
      echo "Install one of:" >&2
      echo "  sudo apt-get install -y chromium-browser   # Debian/Ubuntu" >&2
      echo "  sudo dnf install -y chromium               # Fedora/RHEL" >&2
      echo "or fetch Playwright's bundled browser: npx playwright install chromium" >&2
      ;;
    wsl)
      echo "No Chrome/Chromium binary was found inside WSL or under /mnt/c/Program Files." >&2
      echo "Install Chrome/Chromium inside the WSL distro, or install Google Chrome on" >&2
      echo "the Windows host so it is reachable at /mnt/c/Program Files/Google/Chrome/..." >&2
      ;;
    windows)
      echo "No chrome.exe/chromium.exe was found on PATH or under Program Files." >&2
      echo "Install Google Chrome (https://www.google.com/chrome/) and retry." >&2
      ;;
    *)
      echo "Could not detect this OS (uname -s reported an unrecognized value) and" >&2
      echo "no Chrome/Chromium binary could be located automatically." >&2
      ;;
  esac
  exit 1
fi

# --- Headless Linux: provide a virtual display if none exists ----------
# Real desktops (macOS, WSL with WSLg, Windows) already have a display.
# A headless Linux sandbox does not, but headed Chrome still needs one to
# start; Xvfb provides a virtual framebuffer it can render into.
if [[ "$OS_TYPE" == "linux" && -z "${DISPLAY:-}" ]]; then
  XVFB_DISPLAY_NUM="${WIX_HARMONY_XVFB_DISPLAY:-99}"
  XVFB_LOCK="/tmp/.X${XVFB_DISPLAY_NUM}-lock"
  # An X11 lock file's mere existence is not proof a usable Xvfb is behind it: if a prior Xvfb
  # was killed uncleanly (OOM, `kill -9`, a container restart) the lock file survives with no
  # process left to serve the display, and Chrome would then fail against a dead display with
  # only a generic ~20s CDP-timeout error instead of this script's own actionable diagnosis. Per
  # the standard X11 lock-file convention, the file's content IS the owning process's pid (ASCII
  # decimal, whitespace-padded) -- check it directly rather than trusting the file's presence.
  if [[ -e "$XVFB_LOCK" ]]; then
    xvfb_lock_pid="$(tr -d '[:space:]' < "$XVFB_LOCK" 2>/dev/null || true)"
    xvfb_lock_stale=0
    if [[ -z "$xvfb_lock_pid" ]]; then
      xvfb_lock_stale=1
    elif [[ ! -e "/proc/$xvfb_lock_pid" ]]; then
      # BUG FIX (code review, round 3): `kill -0` alone cannot tell "no such process" (ESRCH,
      # truly stale) apart from "process alive, owned by a different user" (EPERM) -- both return
      # the same nonzero exit code. Checking /proc/<pid> directly (this branch only runs under
      # linux, see the OS_TYPE guard above) answers the ESRCH question on its own: no /proc entry
      # means the process is genuinely gone.
      # NOTE (code review, round 6): this is the same EPERM/ESRCH distinction as
      # `skills/wix-replatform/lib/local-state.js`'s `isProcessAlive` (consolidated there with
      # `execution-health-check.js` in round 5), reimplemented here in bash since JS and bash
      # can't share code cheaply. A future fix to one should prompt a check of the other.
      xvfb_lock_stale=1
    elif ! kill -0 "$xvfb_lock_pid" 2>/dev/null; then
      # /proc/<pid> exists (a real process is running under that pid) but kill -0 still failed:
      # this is EPERM, not ESRCH -- a live Xvfb owned by a different UID (e.g. a shared
      # container/sandbox). Misdiagnosing this as dead and deleting its lock would let a second
      # Xvfb start and race to bind the same display. Fail loudly instead of guessing.
      echo "Xvfb lock ${XVFB_LOCK} names pid ${xvfb_lock_pid}, which is running but owned by a" >&2
      echo "different user (kill -0 was denied) -- this looks like a LIVE Xvfb this script does" >&2
      echo "not have permission to inspect or replace, not a stale lock from a dead process." >&2
      echo "Remove ${XVFB_LOCK} yourself once you've confirmed it's safe, or export DISPLAY to" >&2
      echo "point at a display this script can use." >&2
      exit 1
    fi
    if [[ "$xvfb_lock_stale" -eq 1 ]]; then
      echo "Removing stale Xvfb lock ${XVFB_LOCK} (pid ${xvfb_lock_pid:-unknown} is not running)." >&2
      # `|| true`: under `set -e`, an `rm -f` that genuinely fails (permission denied, or the
      # path turning out not to be a plain file) would otherwise abort the script right here with
      # rm's own generic error, before the verification below ever runs. Trust the follow-up
      # existence check, not rm's exit code, to decide whether removal actually happened.
      rm -f "$XVFB_LOCK" || true
      if [[ -e "$XVFB_LOCK" ]]; then
        # BUG FIX (code review, round 3): `rm -f` exits 0 even when it silently fails to remove a
        # path it lacks permission for (e.g. a sticky /tmp directory owned by another user, or the
        # path turning out not to be a plain file at all) -- verify removal actually happened
        # rather than trusting rm's exit code. Falling through here with the lock still present
        # would skip starting a fresh Xvfb below and export DISPLAY at a dead display.
        echo "Failed to remove stale Xvfb lock ${XVFB_LOCK} (no permission, or it is not a" >&2
        echo "plain file?). Remove it manually and re-run, or export DISPLAY yourself." >&2
        exit 1
      fi
    fi
  fi
  if [[ ! -e "$XVFB_LOCK" ]]; then
    if ! command -v Xvfb >/dev/null 2>&1; then
      echo "No \$DISPLAY is set and Xvfb is not installed, so headed Chrome cannot" >&2
      echo "start on this headless Linux machine. Install it, e.g.:" >&2
      echo "  sudo apt-get install -y xvfb   # Debian/Ubuntu" >&2
      echo "  sudo dnf install -y xorg-x11-server-Xvfb   # Fedora/RHEL" >&2
      echo "then re-run this script (or export DISPLAY yourself if you already have" >&2
      echo "a virtual/real display running)." >&2
      exit 1
    fi
    nohup Xvfb ":${XVFB_DISPLAY_NUM}" -screen 0 1280x800x24 \
      >"${PROFILE}/xvfb.log" 2>&1 &
    xvfb_pid=$!
    # An Xvfb that exits at once may already be reaped, and a bare `disown` then fails with "no
    # such job", which set -e turns into an exit before the liveness check below can explain why.
    disown "$xvfb_pid" 2>/dev/null || true
    # A backgrounded Xvfb takes a moment to create its lock file and start serving the display;
    # `sleep 1` then unconditionally exporting DISPLAY assumed it always makes that window, with no
    # check that it actually came up. If Xvfb itself failed fast (missing X extension, a stale
    # /tmp permission problem, port/display already in some other conflicting state), the old code
    # would still export DISPLAY and hand Chrome a dead display -- Chrome would then fail ~20s
    # later against a generic CDP-timeout, with nothing pointing back at Xvfb as the real cause.
    # Poll for the lock file actually appearing (proof Xvfb bound the display), or the backgrounded
    # pid dying (proof it won't), across a short retry window -- the same diagnostic quality as the
    # stale-lock check above this block, rather than a blind fixed sleep.
    xvfb_ready=0
    for _ in $(seq 1 30); do
      if [[ -e "$XVFB_LOCK" ]]; then
        # The lock appearing is not proof Xvfb stays up: it can create the lock and then exit.
        # Re-check the pid after a short settle before trusting the display.
        sleep 0.3
        if kill -0 "$xvfb_pid" 2>/dev/null; then
          xvfb_ready=1
        fi
        break
      fi
      if ! kill -0 "$xvfb_pid" 2>/dev/null; then
        break
      fi
      sleep 0.1
    done
    if [[ "$xvfb_ready" -ne 1 ]]; then
      echo "Xvfb did not come up on display :${XVFB_DISPLAY_NUM} within 3s (lock file" >&2
      echo "${XVFB_LOCK} never appeared). Check ${PROFILE}/xvfb.log for its own error output," >&2
      echo "e.g. a missing X extension, a permissions problem under /tmp, or the display" >&2
      echo "number already being used by something else that isn't Xvfb itself." >&2
      exit 1
    fi
  fi
  export DISPLAY=":${XVFB_DISPLAY_NUM}"
  echo "No \$DISPLAY was set; using virtual display ${DISPLAY} (Xvfb) for headed Chrome." >&2
  echo "If Wix shows a sign-in page, you'll need a way to see/interact with this" >&2
  echo "virtual display - e.g. 'x11vnc -display ${DISPLAY} -localhost -nopw' plus a" >&2
  echo "forwarded VNC port, or take Playwright screenshots to inspect page state." >&2
fi

nohup "$CHROME" \
  --user-data-dir="$PROFILE" \
  --remote-debugging-address=127.0.0.1 \
  --remote-debugging-port="$PORT" \
  --no-first-run \
  --no-default-browser-check \
  "$EDITOR_URL" >"${PROFILE}/chrome.log" 2>&1 &
echo "$!" >"$CHROME_PID_FILE"

for _ in $(seq 1 40); do
  if curl -fsS -m 2 "http://127.0.0.1:${PORT}/json/version" >/dev/null 2>&1; then
    echo "Wix Harmony Chrome is ready on local CDP port ${PORT}."
    exit 0
  fi
  sleep 0.5
done

echo "Chrome did not expose its local CDP endpoint. Check ${PROFILE}/chrome.log." >&2
exit 1

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Node.js

Security

What our scanner noticed· Low risk

  • Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Wix
Publisher
Wix (Official)
Source
wix/skills · skills/wix-harmony-editor · commit d168bc2
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Wix.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download wix-harmony-editor.zip