How I use Claude Code with Base44, and the deploy traps to avoid

To use Claude Code with Base44, connect your app to GitHub, let Claude Code work on a branch of that repo, then merge into main and publish in Base44. It works really well, as long as you know three traps first: Base44's own bot commits to main, redeploying the same version doesn't rebuild anything, and Base44's build pins the date to 2022.

This whole site was built that way. When I counted on 28 September, main had 109 commits:

That's not me being lazy (well, not only lol). My job is deciding what gets built, reading what comes back, and being the one who presses merge. Here's my setup, then the traps I hit.

What Base44 puts in your repo before you do anything

When I connected my app to GitHub, the very first commit already had three files for agents and humans: CLAUDE.md, AGENTS.md and a README.md. I didn't write any of them. Base44's bot did.

Read all three. Claude Code loads CLAUDE.md at the start of every session, and that points it at the other two, so they shape everything it does in your repo.

Two Base44 extras make Claude Code much better at Base44 work.

The first is Base44's skills. The docs (opens in a new tab) describe them as "self-contained instructions that teach AI agents how to perform specific tasks with Base44". Install them with npx skills add base44/skills, or add -g to install them globally. (New to the idea? Here's what an agent skill is.)

The second is Base44's MCP server (opens in a new tab), which the docs sum up as: "Create and manage Base44 projects, and edit an app's code in its sandbox, from AI assistants like ChatGPT, Claude, and Cursor."

Claude Code can talk to Base44's API too. When I renamed my app and rewrote its description for SEO, Claude Code did it through the API. No dashboard clicking.

My workflow, start to finish

Claude Code never works on main. It gets a branch, a clear brief and a definition of done.

Big jobs get split. My speed pass was six packages, each on its own branch with its own Claude Code agent, and a final package merged the rest and re-measured everything. That's how I cut 91 KB of JavaScript without changing a pixel.

Nothing counts until it's proven. Lint and build have to pass, and anything visual gets tested in a real browser. The blank-page fixes on this site went through about 1,000 Chromium checks and 71 WebKit checks before I trusted them (the full story is here).

Then it opens a pull request with the numbers in the description. I read it, check the files changed, and merge into main. The merge syncs into Base44, and Base44's GitHub docs (opens in a new tab) are clear about the last step: "After syncing, click Publish in the top right corner of your Base44 app to make the changes live for users."

One warning from the README Base44 wrote, and I agree with it: publish from the dashboard, not with base44 deploy, because "a CLI deploy ships your local tree directly, bypassing the sync, and the deployed state silently diverges from the repo."

My opinion changelog on AI coding agents is a mess, by the way. I pay for Claude Code and Codex now. This workflow doesn't care which one you use (my Claude Code glossary entry has the full embarrassing history).

Trap 1: Base44's bot commits to main

Base44's GitHub sync goes both ways. The docs say "your changes are synced to the connected repository automatically", and with a shared connection, "Commits show Base44 as the author." So what you do in the Base44 builder lands on main as a commit too. My log has one from 26 September: "Add cursor-tracking text and layout styling to home page", from base44-builder[bot].

It also updates packages by itself. On 28 September I merged a pull request at 10:19 UTC, and 25 seconds later base44-builder[bot] pushed "Update base44 packages". Then it did it AGAIN. That afternoon I merged another at 15:52 UTC, and 16 seconds later the bot bumped the Vite plugin to 1.0.44. Twice in one day. Expect it.

If your agent then pushes straight to main from its old copy, git rejects the push, and forcing it throws away Base44's commit. Even on a branch, you want the bot's changes in before you test. Otherwise you're testing against packages main no longer uses. So the rule is simple: pull before you push. Every time.

$ git fetch origin$ git merge origin/main$ npm install$ npm run build$ git push

The merge brings in anything the bot pushed, and npm install picks up any packages it bumped under you.

That package bump matters more than it looks. This site patches the Base44 SDK and framer-motion at build time: each patch finds an exact piece of text in the library's file and replaces it. An upgrade could move that text. So each patch checks first and warns instead of breaking the build:

// Pattern from vite/base44Consent.js (simplified)
for (const p of patches) {
  if (!code.includes(p.find)) {
    this.warn('@base44/sdk changed: the consent edit was not applied');
    continue;
  }
  code = code.replace(p.find, p.replace);
}

After that first bump, I had both patch files re-checked against the new versions. They still apply. If you patch anything in node_modules, re-check it every time that bot commit shows up.

Trap 2: redeploying isn't rebuilding

My sitemap, llms-full.txt and a pile of other files are generated when the site builds. So when does it build?

I tested it on 28 September, using the build timestamp in one of my generated files. Redeploying the same version left the timestamp exactly where it was. A GitHub sync that pulled in new commits changed it.

This bites hardest with scheduled content. My sitemap skips posts dated in the future, so a post that goes live at 07:00 isn't in the sitemap until the next real build. Publishing the same version again won't add it. A new commit will.

Trap 3: the build thinks it's 2022

There's a standard environment variable, SOURCE_DATE_EPOCH, that build tools use to pin dates so builds are reproducible. Base44's build sets it to a fixed date in 2022.

My agent-file generator honoured it, like a good little script. So every generated file said it was made in 2022, and my security.txt looked expired. Nothing errored. It was just quietly wrong.

The fix: only trust the pinned date if it's later than a date you know is real.

function generatedAt() {
  // Base44's build pins SOURCE_DATE_EPOCH to 2022. Ignore anything before our first release.
  const epoch = Number(process.env.SOURCE_DATE_EPOCH);
  const pinned = Number.isFinite(epoch) && epoch > 0 ? new Date(epoch * 1000) : null;
  return (pinned && pinned >= new Date('2026-09-26T00:00:00Z') ? pinned : new Date()).toISOString();
}

My security.txt expires a year after the build that made it. Here's the live one after the fix:

$ curl -s https://aatmanjain.com/.well-known/security.txt | grep ExpiresExpires: 2027-09-28T00:00:00.000Z

If anything you generate has an expiry date (security.txt has to), check what date your build thinks it is.

A bonus trap, if you have a blog

Base44 only prerenders routes written out as literal paths in App.jsx, so pages on a /:slug route can reach crawlers as a bare shell. Claude Code won't know that unless you tell it. I wrote up why Google can see an empty page on your Base44 app, with the two-curl test I use to check.

Checklist

FAQ

Can you use Claude Code with Base44?

Yes. Connect your Base44 app to GitHub, let Claude Code work in that repo, and merge changes into the main branch, which syncs back to Base44. Base44 also publishes official agent skills and an MCP server that Claude can use.

Does Base44 commit to my GitHub repo?

Yes. Changes made in the Base44 builder sync to the repo as commits, with Base44 as the author on a shared connection, and on my site its bot also pushed package updates to main on its own. Always pull before you push so you don't overwrite those commits.

Why didn't redeploying my Base44 app update my sitemap?

In my test on 28 September, redeploying the same version didn't rebuild the app, so nothing generated at build time changed. A GitHub sync that pulled new commits did trigger a new build. Push a real commit when you need generated files refreshed.

Should I publish a GitHub-synced Base44 app with the CLI or the dashboard?

The README Base44 adds to a synced repo says to publish from the dashboard, not with base44 deploy. A CLI deploy ships your local files directly and skips the Git sync, so the live app can drift away from what's in the repo.