Yes, two ways. One GitHub App install on one repository, or a GitLab project access token you paste, and every change you approve becomes a commit on your default branch, named for what it does. Undo is another commit, and nothing is committed before you approve it.
This is the install path for the team whose site is code, not WordPress and not a hosted builder. The full inventory of what the agent does once it is on a site applies here too; a connected repository is simply the hands it uses to carry that out.
Two doors, one per host. On GitHub you install the Reflexa App on exactly one repository, approved from GitHub's own settings, the same kind of install any other GitHub App uses. On GitLab there is no app to install; you generate a project access token in the project's own settings and paste it into Reflexa's site settings once. Either way the agent has one repository to work in and nothing beyond it.
You see the change first, exactly as it will be written, before anything is sent. Once you click apply, it becomes a commit on your default branch, named for what you approved, whether that is the robots rules, the Organization data on every page, the sitemap, /llms.txt, a page's title, description, opening or FAQ, or a redirect. Nothing is committed before that click, the same rule the agent follows for a switch or a page edit on any other site it is installed on.
Why it matters: a commit is not a hidden write. It shows up in your repository's own history, with your usual review tools if you want to look, the way any other change to the codebase would.
A static repository, one that is served the way it is written, takes every kind of change the agent makes anywhere else. A repository that runs through a build step before it is served is split: the agent commits the files a build does not touch, and your own build and deploy carry the rest.
| Change | Static repository | Built repository |
|---|---|---|
| robots.txt rules | Commit | Commit |
| Sitemap | Commit | Commit |
| /llms.txt | Commit | Commit |
| Redirects | Commit | Commit |
| Organization data on every page | Commit | Follows your build and deploy |
| Page title, description, opening, FAQ | Commit | Follows your build and deploy |
Bottom line: the split is not a limit of the agent, it is the same line your own deploy already draws between a file it serves directly and a page your framework renders at build time.
Because a commit landing on your default branch is not the same thing as a build picking it up and the live page actually serving it. The same discipline the agent uses for a WordPress revision or a switch, reading the live page again instead of trusting its own report, applies here too: after a commit, it re-reads the live site rather than marking the change done the moment the commit exists.
Why it matters: a build that fails, a cache that has not cleared, or a deploy still in progress all mean the commit is real but the page has not changed yet. The agent's own record should say that, not the opposite.
The change itself is the same; only the hand that applies it differs. On WordPress the same edit lands as a revision you can restore. On Shopify or Webflow it goes through that platform's own API, reaching only what that API exposes. On a repository, it lands as a commit, with your own repository's history as the undo trail. What counts as a change the agent can make at all is answered once, for every one of these hands.
None of this needs a developer's whole afternoon:
Bottom line: connecting the repository changes nothing by itself. The first commit still waits for your click, same as every other change the agent proposes.
Depends on the host. On GitHub it is one App install on one repository, approved once in GitHub's own settings. On GitLab there is no app; you generate a project access token yourself and paste it into Reflexa's site settings.
Only the files that do not pass through the build: robots rules, the sitemap, /llms.txt and redirects. A page's title, description, opening or FAQ goes through your normal build and deploy like any other content change, because that is what already decides what ends up on the live page.
No. You see the exact change, the files it touches and the commit message it will use before anything is sent, and nothing is committed until you click apply.
Undo is another commit. The agent reverts the change the same way it made it, named for what it is undoing, so the history stays readable rather than rewritten.
It checks again. A commit landing on your default branch is not the same as a build picking it up and the live page actually serving it, so the agent re-reads the live site afterward rather than reporting success from the commit alone.
The free check reads your live site the way AI crawlers do, no repository access needed, evidence included.
The product: Reflexa Agent · how it works · på svenska