An assistant connected to your store can rewrite your storefront design: sections, layout, colours, fonts and copy, on any of your pages. It works on the same saved design the builder edits, so a change made this way shows on your live store immediately. For editing inside the builder instead, see Using the builder and Building with the AI assistant.
The three levels of access
- Read storefront design: the assistant can look at your pages and tell you what is on them. It changes nothing.
- Edit storefront design: the assistant can save changes to your live storefront.
- Add custom code: needed on top of the other two before an assistant may touch custom JavaScript, custom CSS or a custom code section. Only the store owner can grant this, and it is never offered as part of a routine connection.
The safe order to work in
- Let it read the page first. Section positions differ from page to page, so a change composed without reading is guesswork.
- Ask for a preview. An assistant with read access can run the whole change through the real checks and show you the result without saving anything. This costs nothing and catches mistakes before they are live.
- Then approve the edit permission and let it save the same change for real.
Reading and previewing need only Read storefront design, so you can hold back the edit permission until you have seen what the assistant intends to do.
Storefront changes cannot be undone
Storeep keeps no version history for changes made this way, and the builder's undo button does not reach them. Once saved, a change is live and the only way back is to put the old values in again. Before you approve an edit, ask the assistant to record the current values so it can restore them if you dislike the result. The assistant is told this too, so a good one offers it without being asked.
What is refused even with edit access
- Custom code. Any change that would end up altering custom JavaScript, custom CSS or a custom code section is refused unless the owner granted Add custom code. That code runs on the page where customers type their card details, which is why it is held apart.
- A checkout nobody can be reached at. A change that would leave the checkout requiring neither email nor phone is refused and nothing is saved, because orders would arrive with no way to contact the customer.
- Changes that match nothing. If a change is valid but does not actually alter anything, it is refused rather than reported as done, so an assistant can never claim an edit it did not make.
Markets and pages
Eleven pages can be edited: home, product, landing, collection, cart, checkout, thank you, search, policy, contact and the 404 page. See Which pages you can edit.
- Every market carries its own full copy of the design settings and of every page. Colours changed for one market do not reach another, so a two-market store is two sets of changes.
- Markets drift apart over time. One market's home page may carry a section another does not, so the assistant has to read each market's own page before changing it.
- Shared sections still need care. The header, footer and announcement bar exist on each page separately, so changing them everywhere means touching each page.
Rules and corner cases
- Split large redesigns. A very large change sent in one go can fail, sometimes with a message about re-authorizing. That is the size of the change, not your connection expiring, so smaller batches fix it and reconnecting does not.
- A wrong position is refused, not applied elsewhere. Changes name the section they target, so pointing at the wrong place comes back as a rejection and costs you nothing.
- Ask for a second confirmation on a live storefront. The Ask me again before every change option, ticked when you connect the app, is the safest way to let an assistant near your published pages.
- Every change is logged. See it under Recent activity in MCP connections.