Skip to content

🦞 igor-claw: CONNECT.md β€” document the no-attach-existing-site CLI gap - #944

Open
ayal wants to merge 1 commit into
mainfrom
igor-claw/document-no-attach-existing-site-gap
Open

🦞 igor-claw: CONNECT.md β€” document the no-attach-existing-site CLI gap#944
ayal wants to merge 1 commit into
mainfrom
igor-claw/document-no-attach-existing-site-gap

Conversation

@ayal

@ayal ayal commented Aug 10, 2026

Copy link
Copy Markdown
Contributor

Summary

A user with a pre-provisioned headless site (siteId/clientId handed over by Wix's own onboarding UX before any code existed) had no supported way to attach a Wix CLI project to it. init, create, and headless link all unconditionally provision a brand-new site+app pair β€” confirmed in wix-cli source: getHeadlessInitCommand's init command takes zero options, and create-headless's CommandOptions has no siteId/clientId field.

Hand-writing wix.config.json with the existing, correctly-authorized siteId/appId looks like it works β€” every backend REST call succeeds (app install, content seed), and even wix release itself reports success β€” but the deployed frontend never serves; Wix's edge returns a generic 404 as if the site doesn't exist. Root cause (from wix-cli source): init's create-project.ts calls Dev Center's updateOAuthApp(..., redirectUrlWixPages, origin: 'other') to register the app as the site's active frontend β€” a step only reachable through init/create/link, never exposed as a standalone/repairable call. No CLI command, REST call, or wix release output flags this as missing.

This is a real product/CLI gap (needs a design decision β€” new command/flag, or a "claim existing site" mode), so no code PR for the underlying gap. This PR instead updates the skill so a future run doesn't burn time hand-authoring a config that can't work, and instead surfaces the limitation + uses the field-tested fallback (provision a fresh site+app pair, re-seed against it).

Change

skills/wix-headless/references/managed/CONNECT.md β€” new caveat after Β§1: stop and tell the user rather than hand-write wix.config.json around a pre-existing siteId, and the fallback flow that's confirmed to work.


Opened automatically by an AI agent on behalf of Ayal (ayalg@wix.com). Report thread: https://wix.slack.com/archives/C0BDXM5LLE7/p1786351421432449

init/create/headless link always provision a brand-new site+app pair β€”
there's no supported way to target a pre-existing siteId/clientId (e.g.
from Wix's own headless onboarding). Hand-writing wix.config.json around
this looks like it works (every backend REST call + wix release succeed)
but the frontend never serves β€” the site's origin never gets registered
with the platform edge, since only init/create/link reach that step.

Adds a caveat telling the agent to stop and ask rather than burn a run on
hand-authored-config debugging, plus the field-tested fallback: provision
a fresh site+app pair via init/create and re-run Setup/Seed against it.

Opened automatically by an AI agent on behalf of Ayal (ayalg@wix.com).
Context: https://wix.slack.com/archives/C0BDXM5LLE7/p1786351421432449
@ayal
ayal requested a review from ozsay August 10, 2026 08:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant