Build apps by chatting in Newt

Create, change, preview, and deploy an app purely by chatting in Newt — no GitHub, plugin, or terminal.

Tell Newt's chat what you want, and the Agent creates the app and changes its code.
It carries on through validation, saving, and preview deploys without asking again at every step, and progress stays in the chat.

You don't need a GitHub account, the Claude Code · Codex plugin, the CLI, or development tools on your computer. Code is saved in the in-company Git repository AxHub creates for each app.

The existing plugin · CLI · GitHub paths stay as they are. They're covered in Quickstart and Build and deploy your app.

Before you start

Check	Details
Newt sign-in	Install Newt the way your company told you, and sign in with your AxHub account.
Company (tenant)	The company you'll build the app in must be selected. Apps and permissions are separate per company.
App development feature	Newt app development must be turned on for your company. If it's off, the Agent tells you so — ask your company admin.
Permissions	To create an app you need permission to create apps in that company. To change an existing app you must be its owner or co-owner or have write access, and to deploy you need deploy permission.
Agent development permission	The Agent you're talking to must have the coding tools (read · write · edit · bash) allowed. Your default Agent, Newt, has them allowed. A Newt created earlier gets them once the next time you open Newt (unless you changed that Newt's tool settings yourself). An Agent you made yourself may not — you check this in step 3.

Apps it can work on — apps that use AxHub's own Git repository (Docker · Compose · static deploys). Apps you create in Newt start from the Next.js default template (Docker deploy). Apps connected to GitHub, AxHub plugin-type apps, archived or suspended apps, and apps whose repository is being migrated can't be changed in Newt — the Agent tells you why and stops.

Where code runs — the Agent changes and validates code in an isolated workspace (sandbox) with no access to the internet or company secrets. It's based on Node 20 (v20.20.2) · npm 10.8.2.

Installing packages — the Agent can add packages from the public npm registry (registry.npmjs.org). Installation happens not in the Agent's workspace but in a separate install environment AxHub starts, which reaches only the registry and receives only package.json and the lockfile. If there's no lockfile (package-lock.json) or the dependencies in package.json changed, it writes the lockfile or updates only what's needed, and that file is saved along with the changed code. A lockfile that already matches is never rewritten. These can't be installed (dependency_resolution_failed):

Packages given as a Git address, file path, or URL, and workspace packages
Packages that need to run scripts when installed
Installs that don't finish within 5 minutes, or a dependency tree that's too large

Deploys build separately with the repository's Dockerfile — the default template installs the same versions with npm ci when a lockfile exists.

Follow along

These are all the steps a person takes. Creating the app, preparing dependencies, validation, saving, the first private production deploy, and staging setup are done by the Agent and AxHub. Step 7 is needed only the first time you open a private app.

Open Newt and check the company

Check the app development feature

Ask in the chat:

Show me the apps I can change

If the Agent lists apps you can change, the feature is on. If the feature is off or you lack permission, it tells you why.

Check the Agent's development permission

Then ask:

Can you build and change apps with this Agent?

If it says yes, you're ready. Your default Agent, Newt, can from the start. If another Agent says no (agent_coding_not_allowed), that Agent doesn't have the coding tools (read · write · edit · bash) it needs to read and change code. Even if you ask it to build anyway, it stops without creating an app or repository. Talk to Newt, or ask an admin to allow that Agent's tools.

Describe the app

Write what you want in terms of the result. You can copy this sentence as-is.

Build an app where our team registers work requests and checks their status. Save the title and request details, and the requests and their status must still be there after a refresh. Name the app Request Inbox.

This sets a goal of build and preview. It doesn't deploy to production or publish to the internet — if you want that too, say something like "build it and deploy to production". What runs automatically is explained in What it does on its own and what it asks below.

The app's address comes from its name. Names that aren't plain English letters get an address of app- followed by random characters.

Watch the progress

The task keeps running on the server after the Agent replies. Each time the stage changes, an app task message appears in the chat.

Create the app — AxHub creates the app and its Git repository and adds the template code.
Write code — the Agent builds the requested feature in the sandbox.
Validate — in the same sandbox it runs npm run build (and npm test if a test script exists). If that fails, the Agent reads the error and fixes it on its own, up to three times.
Save — code that passed validation is saved to the newt/dev branch of the Git repository.
Prepare the preview — a new app needs one production deploy before staging can be turned on. So it does a first production deploy kept private to you, then turns on staging.
Deploy the preview — the saved version is deployed to staging, and it checks that the app responds.

The final check only confirms that the service responds. Whether features like registering a request actually work is something you check yourself in step 8.

You can close Newt and the task keeps going. When you reopen it, the app task messages that arrived in the meantime appear in order.

Open the preview link

When the preview is ready, the app task message carries a preview link. When you click it, Newt first checks with AxHub — whether you can still see this app and whether this link is the latest version. Once confirmed, it opens in your default browser.

If it doesn't open, the reason appears right under the link. If it says a newer version exists, click the link in the most recent app task message. Details are in How links open.

Sign in in the browser if asked

Because the app is private, the browser may show the AxHub sign-in screen. Sign in with your company account and you're taken back to the preview. If you're already signed in, there's no such step.

Register work and look it up again

Register one request in the preview, then refresh the page. If the request you just registered and its status are still there, your first result is done.

The preview (staging) uses a different database from production. Test data you enter here doesn't mix into production (Deploy through staging).

Change it twice, then continue the next day

Keep talking in the same conversation. Each change reruns write code → validate → save → preview.

Add a filter to Request Inbox to view requests by status

Add an assignee field to Request Inbox requests

The next day, just name the app in a new conversation. It continues from the last saved version. The work is tied to the app's Git repository, not to the conversation or the Agent.

Add a due date to the Request Inbox I built yesterday

Deploy to production

When you're done checking the preview, say:

Deploy Request Inbox to production

For apps that use staging, the build you checked in the preview goes to production as-is. Depending on company policy it goes live right away, or after an admin approves — while waiting, the app task message shows it as awaiting approval. Visibility stays the same. To open it beyond the company, say so separately, like "publish Request Inbox to the internet".

What it does on its own and what it asks

Within the goal you gave, the Agent carries on without asking at each step. It doesn't do things outside that goal.

When you say	What the Agent carries on with, without asking
"build it" · "change it"	Writing code · validation · Git save · private preview. For a new app, also the private first production deploy and staging setup the preview needs
"deploy to production" · "build it and deploy"	All of the above + releasing that app to production. For staging apps it requests the release and waits if approval is needed
"publish it to the internet"	Up to requesting the review that widens visibility. An admin approves it
"add a due-date column to the requests table" · "change an environment variable"	Only the setting you asked for — create a table, add a column, add or change an environment variable, set or clear a staging-only value

In these cases it stops and asks in the chat.

When the goal is unclear — if it isn't sure what you want, it holds production deploys, publishing, and setting changes and asks. Writing code, saving, and the private preview continue (goal_unverified).
When it can't tell which app — if several apps share a name, it asks which one. It never writes to an arbitrary app.
When a secret is needed — don't paste secrets like API keys into the chat. Register them yourself on the app console's environment variable screen (Set environment variables), and the Agent refers to them by name only.

It never does these.

Effects you didn't ask for — if you only said "change it", it doesn't deploy to production, change visibility, or change settings.
Stand in for approvals — it never skips a review or admin approval, or shows something as approved when it isn't.
Risky data changes — dropping tables or columns, arbitrary SQL, and editing data rows aren't done through this path.
Widen the goal from someone else's words — the goal widens only from your own words as this conversation's owner. Words other people write in a shared conversation, or the Agent's own judgment, never widen it.

Permissions are re-checked at that moment before every stage. If you lose a permission midway, it stops there (permission_revoked).

Where progress shows up

App task messages — added to the chat each time the stage changes. If Newt is open they appear within seconds; if it was closed, they appear in order when you reopen it.
Ask for the current status — ask "how far along is the Request Inbox task?" and the Agent looks up the latest status of the same task. It doesn't start a new one.
What a result contains — save status (save number · time), validation results (commands run · exit codes · last output), preview and production status with the time checked, and on failure the error code · stage · cause · next action.
Stop it — say "stop the Request Inbox task" and it stops in-progress coding and any deploy that can be stopped. Code already saved and deploys already finished aren't rolled back, and a review already requested stays requested. The message tells you what remains.

Only one task runs per app at a time. If you ask for more while one is running, it tells you about the existing task (operation_in_progress). A task paused waiting for your answer also counts as running — answer its question, or stop it and then ask again. Status questions and stop requests are handled right away even while coding is running.

How links open

Links in app task messages (preview · production) open only after AxHub re-checks them at the moment you click. For deploy logs, ask in the chat instead — for example "show me the Request Inbox deploy logs" — and the Agent shows the relevant part.

Check result	What you see
Latest, and you can see it	Opens in your default browser
A newer version exists	A note under the link says a newer version exists. Use the link in the most recent app task message
Not ready yet · no permission · app is down	The reason and what to do appear under the link

App addresses the Agent writes directly in its reply go through the same check. Anything that isn't this company's app address won't open.

Where code is saved

In the in-company Git repository AxHub created for the app. Newt saves only to its newt/dev branch.
The default branch (main) is never touched. So saving alone never starts a deploy, and deploys use only the exact version the Agent saved.
If the same branch was changed elsewhere by the time it saves, it stops instead of overwriting (git_conflict).
These files are left out or blocked.
- Left out of the save: node_modules · .git anywhere, and .next · .turbo · out · coverage · .newt-sandbox (where build tools keep their own settings and temporary files) in the top folder
- Stops the save: .env · .env.* files (.env.example is fine), symlinks
One save can hold up to 4,000 files · 24 MiB in total · 16 MiB per file, and must stay under 32 MiB compressed (source_too_large).

If you get stuck

When something fails, the app task message shows the error code · stage · problem · cause · next action together. What each code means and how to fix it is in Newt app development errors.

Newt app development errors

What each error code means and what to do next

Deploy through staging

How the preview environment and production release work