Documentation

The agent is powerful inside your project and deliberately powerless outside it. Knowing where that line sits saves you from asking for things it will refuse.

It can

Create, read and edit files anywhere in your project tree. Install packages from the allowlist. Run the build and the test command. Read the build output and repair what broke. Import a public git repository you name, after a security scan. Write its own project rules file so a later session understands the stack.

It cannot

Reach any host outside the allowlist — the sandbox has no general internet access, so it cannot call a random API, exfiltrate your code, or download an arbitrary binary. Read another customer's project. Read your environment variables' values. Change your billing, your plan, your domains or your account. Deploy to a live hostname without your explicit approval.

Secrets

Never paste an API key into the chat. Set it with lunax env set or in the dashboard: values are encrypted server-side, injected into your running site, and never shown back to the agent or written into your repository. A key that reaches the chat is in the session history, and the session history is part of the context the model sees.

Project rules

Each project carries a .lunax/skills/project.md describing its stack, its commands, and the conventions the agent should follow. The first build writes one; after that it is yours. Edit it, reorganise it, or replace it — later sessions read your version, and it survives every rebuild. It is the fastest way to stop repeating the same instruction in every message.

A project rules file describes style and structure. It cannot grant the agent a capability, name a credential, or widen a permission — those are decided by the platform, not by a file inside your project.