Skip to main content
Use a local coding agent to customize your cloud site’s components, layouts, styles, settings, and pages. Work locally, then push a checkpoint for review. The same connection can write drafts in the cloud editor and upload media. The pairing code grants access to the managed repository. This workflow uses Lettercamp-managed repositories after the site’s first build. For a site connected to your own GitHub repository, use your normal Git workflow.

Connect your agent

In Settings → Agent connections, choose Copy instructions under Edit with your AI agent. Paste the instructions into your local agent, then describe your changes. The command looks like this:
The command downloads the CLI when needed. Your computer needs the supported Node.js version. The code expires after 10 minutes and works once. The connection grants access to this site’s source, previews, shared posts, and media library. To let the agent publish saved page changes, select Allow publishing saved site content before copying the instructions. Connections expire after 90 days. Choose Disconnect on the same settings page to revoke one. connect creates a folder named after the site’s slug, prints its absolute path, and writes an AGENTS.md with component conventions and development instructions. Credentials and synchronization state stay in your local Lettercamp configuration directory, outside the publication. Choose another folder with --directory:
The folder must be empty or already connected to the same site. Reconnecting preserves local edits; use pull to fetch new source. An interrupted checkout can resume with the same command when the CLI has saved the redeemed connection. Otherwise, copy a new code from the website.

Develop and push a preview

From the downloaded folder, run:
Use local preview for visual iteration and check to verify Cloud compatibility. push checks imports, saves a source commit, builds a cloud preview, and waits for its URL. A build failure exits unsuccessfully and reports the error. Fix your files and push again. Failed builds may already have saved their source commit. The checkpoint goes to a preview branch. Other publishing operations keep using the production branch. Local edits are not uploaded automatically. Production keeps serving its current build until you publish. Anyone with a preview link can view it; preview responses request that search engines do not index them. The preview in Settings → Agent connections updates after a successful push. Choose Publish this preview to make that exact build live. If source or the site’s address changed afterward, pull and push a new preview first. The existing deploy command publishes directly and is separate from this review workflow.

Pull remote changes

status reports local changes, remote changes, shared page edits in the web editor, and the latest build status and error. pull updates files changed only in the cloud and preserves files changed only locally. If both sides changed a file differently, it reports a conflict without changing source files or the base revision. It does not automatically merge lines within a file. Inspect conflicts with pull --json. Its remoteFiles contains conflicting remote files with base64-encoded content; an absent remote file is a deletion. After comparing versions, resolve named files explicitly:
You can provide multiple paths or combine the options for different files. Keeping local accepts the remote revision as the base while retaining your local version for the next push. Shared page edits in the web editor are reported separately. They remain in the editor when you push or publish a code preview; only committed source is included. If another editor publishes while you work, pull to reconcile the new production source with your local changes, then push another preview.

Write a shared post

Run these commands from the connected folder. The web editor can open a saved draft immediately. You can read the body from a Markdown or MDX file without frontmatter, or pass --file - to read from stdin.
Post commands return JSON. Use post.id and post.revision from the response when updating. If another editor saved first, read the latest body and revision, reconcile the changes, and retry. Only supplied fields change. Use --clear description to remove optional metadata. See posts update --help for title, authors, cover image, and other metadata options.

Upload media

Use the returned URL in a post, component, or site setting. The same connection supports images, fonts, and videos. See uploads for supported formats and how to recover a previous upload.

Publish saved posts

New posts start as drafts. To include a post in the next build, run posts update <id> --revision "<current revision>" --status live. When you want to publish all shared saved page changes with the current production settings, use a connection with publishing enabled and run:
The command returns a queued deployment ID. Check publication in posts get or posts list for progress. A matching liveDeploymentId confirms the deployment is live. Posts still marked draft stay out of the public build. For local component or layout changes, use push and review the resulting code preview in Settings → Agent connections.

Options and recovery

If a push is interrupted or you use --no-wait, run push again to resume the saved checkpoint and wait. New local edits remain on disk for the following push. Use status --json to check progress. Finish the pending push before pulling.

Included files

Synchronization includes settings.json and regular files in pages/, components/, lib/, styles/, assets/, and public/. It supports 2,000 files, 5 MB per file, and 10 MB total. Use hosted URLs for large assets. Existing public files from a CLI deployment are downloaded into public/ and count toward these limits. Hidden files, credentials, symlinks, build output, node_modules, package.json, and AGENTS.md are not synced. Follow Cloud’s supported imports. lib/public-files.json is reserved for direct deployments and must not be added to a connected workspace.