The OpenClaw config fields that look optional but will cause problems if you skip them

Six OpenClaw config fields to set before your agent costs you money, locks you out, or loses context mid-session.

Time estimate: 10 minutes to check all seven fields. Add 5 minutes per field you need to fix. If you fix gateway.bind or exec security, restart the gateway when done.

Why “optional” in OpenClaw does not mean “safe to skip”

OpenClaw uses safe defaults wherever it can. For most fields, the default is genuinely fine: you can leave the gateway port at 18789 forever without consequence. But a handful of fields have defaults that are correct for a development laptop and wrong for anything else. The documentation lists them as optional because OpenClaw runs without them. But an OpenClaw optional config left at defaults is how broken setups happen. What it leaves unsaid: running without them means running with development defaults, which optimize for easy setup, not for production safety or cost control.

The seven fields below share a pattern: they have no visible failure at setup time, they cause subtle or invisible failures after days or weeks of use, and they are each a single config change plus a restart to fix.

The cost of skipping them:

• gateway.bind at default: on a VPS or cloud server, anyone who can reach your server’s public IP can talk to your agent as if they are you; on a home machine behind a router, the risk is lower but not zero (depends on your router’s port forwarding)
• exec security at default: that same person can run shell commands on your server through your agent
• Missing model fallback order: when your primary model goes down, your agent picks whichever fallback it chooses, which may be the most expensive one you have configured
• No contextTokens set: your agent hits an invisible token wall, triggers silent compaction (automatic summarization of older messages to free up space), and forgets everything that happened in the first half of your session
• Memory scope not set: all memories from all sessions share one bucket, agents on different tasks share each other’s context, and old sessions poison new ones
• No API key validation on save: a typo in an API key saves silently, every tool call fails with a cryptic error, and you spend an hour debugging the wrong thing
• compaction.model not set: compaction fires using your primary model, the most expensive one you have, with no notification

Field 1: gateway.bind (the config field to set first)

What it is: gateway.bind is the network address the OpenClaw gateway server listens on. “Binding” to an address means the server declares: I will only accept connections coming to this specific address. Think of it as the front door of your agent, but with a selector for which street the door opens onto. The bind address controls who is allowed to knock.

The default: On most OpenClaw installs (npm install on Linux, for example), the gateway binds to 0.0.0.0, which means all network interfaces. Docker installs bind to the container network by default, which behaves differently depending on your Docker network configuration. On a laptop that never leaves your home network, this is usually fine. On a VPS, a cloud server, or any machine with a public IP address, this means your agent is reachable by anyone on the internet who finds your server’s IP and port.

What breaks: There is no authentication layer on the agent interaction endpoint. Anyone who finds your gateway can send commands to your agent and have them execute. They can read files, trigger tool calls, access API keys stored in your config, and send messages through any channel your agent controls. The gateway does not log failed attempts or alert you. You would not know it was happening.

Port scanners probe the internet continuously for open ports. OpenClaw’s default port is 18789. An open 18789 on a VPS IP gets noticed. The gateway endpoint requires no password. A script that sends a message to an open gateway takes five lines of code. The ClawHub security incident in March 2026, where over 800 malicious plugins were identified affecting more than 40,000 instances, showed how quickly gateway access becomes a supply-chain risk when the boundary is not set explicitly.

Check the current value of gateway.bind in my config. Then run this command and show me the full output: ss -tlnp | grep -i openclaw. If ss is not available, try netstat -tlnp | grep -i openclaw instead. In the output, tell me whether the address column shows 127.0.0.1 (loopback only) or 0.0.0.0 (all interfaces). Tell me in plain language what this means for my security.

Field 2: exec security

What it is: exec security controls what shell commands your agent is allowed to run on your server. The exec tool is how your agent runs commands, reads files, and interacts with your operating system. The security setting defines the boundary.

The default: The default exec security mode is full, meaning the agent can run any shell command with no restrictions. This is useful during setup when you want the agent to help you configure things. It is a serious risk to leave in place on any machine you care about.

What breaks: If anyone can reach your gateway, they can ask your agent to run shell commands. With exec at full, that includes anything the user running OpenClaw can do: reading any file, deleting directories, installing packages, exfiltrating data. Even without a malicious actor, prompt injection attacks can trigger exec calls you never intended. Prompt injection is when someone embeds a hidden instruction in content your agent reads (an email body, a Discord message, a document) and the agent follows that instruction as if you gave it. The same risk applies to any channel your agent monitors: Discord, Telegram, email, webhooks. If someone can send your agent a message through any of those channels, they can embed an instruction in the message body. With exec at full and no approval gates, the agent runs it. Prompt injection is a risk if your agent monitors any external channel.

Check the current value of agents.defaults.tools.exec.security in my config. Tell me what it is set to, what each possible value means, and whether my current setting is appropriate for a production instance. If it is set to “full”, explain what that allows and what I should change it to.

Field 3: agents.defaults.model and fallback order

What it is: This setting tells OpenClaw which AI model to use for every conversation. When the primary model is unavailable (rate limit, API outage, quota exhausted), OpenClaw falls back to the next model in the fallback chain. The fallback chain runs automatically. OpenClaw does not send a notification when it switches models unless you have configured an alert for model switches.

The default: If you have not set a fallback order, OpenClaw picks the next available configured model in an undefined order. In practice, this means it may fall back to a different provider than you expect, including more expensive models you configured for specific tasks but did not intend as your general fallback.

What breaks: You get a bill for models you did not intend to use. If you configured a high-capability expensive model for specific tasks and a cheaper model for general use, an undefined fallback may use the expensive one whenever your primary is unavailable. With no alerting, this runs silently until you see your API bill.

Show me the current value of agents.defaults.model and agents.defaults.fallbackModels in my config. List every model I have configured under models.providers, including the provider name and model name. Tell me: if my primary model goes down right now, which model would the agent fall back to, and is that the model I would want it to use?

Field 4: agents.defaults.contextTokens

What it is: contextTokens sets the maximum number of tokens (a token is roughly one word or punctuation mark) that a session can hold before OpenClaw starts compacting older messages. Think of it as the size of the agent’s working memory for any single conversation.

The default: OpenClaw ships with a contextTokens default of 16,384 tokens (16k). That works for quick interactions. For long working sessions that run more than 20 minutes (research tasks, multi-step implementations, extended back-and-forth), the default fills up and triggers automatic compaction. Compaction summarizes older messages to free up space. The summaries are useful but not lossless. Details from earlier in the session get compressed.

What breaks: Your agent forgets things you told it in the first half of a session. Instructions given early get compressed. You reference something from earlier, the agent does not have it anymore, and you get an incorrect or confused response. The compaction happens silently. No notification, no indication that context was lost. The agent continues responding normally. You will not notice until the output starts diverging from what you expected.

What is the current value of agents.defaults.contextTokens in my config? What is the maximum context window for my current primary model? Is my current contextTokens setting less than the model’s maximum? If my sessions regularly run longer than 20 minutes, what would you recommend setting contextTokens to?

Field 5: Memory scope

What it is: Memory scope controls which memories are visible to which sessions. Scopes are like labeled folders for memory. A memory stored in scope “project-alpha” is only retrieved when a session is running under that scope. Without explicit scopes, all memories share a single default bucket.

The default: No scope is configured. All memories go into one shared pool. Every session pulls from the same pool regardless of what it is working on.

What breaks: Memories from unrelated tasks bleed into each other. If you use OpenClaw for work tasks and personal tasks, the agent recalls personal context during work sessions and vice versa. More seriously, if you run multiple agents or persistent sessions on different projects, their memories contaminate each other. A decision made in one project context gets recalled in an unrelated project and influences the response. The agent does not flag this as cross-context contamination. It just uses the memory, because all memories are in the same bucket.

Are memory scopes configured in my setup? Show me the current memory configuration including any scope settings. If no scopes are configured, explain what the risk is of having all memories in a single shared pool and what I should do about it for my specific use case.

Field 6: API key validation

An API key is a password-like string of characters that proves to an AI provider (Anthropic, DeepSeek, OpenAI, etc.) that you have an account with them and are allowed to use their service. When OpenClaw makes a call to generate a response, it sends this key along with the request. If the key is wrong, the provider rejects the call.

What it is: OpenClaw stores API keys (the credentials you use to access AI providers like Anthropic, DeepSeek, or OpenAI) in your main config file (openclaw.json). Some plugins also store their own copy of an API key separately, which is why a key rotation can require updating multiple places. When you add or change a key, OpenClaw saves whatever value you provide without verifying that it is valid before saving.

The default behavior: No automatic validation. This is a design choice, not a bug: validating a key on save would require making a live API call to the provider every time you edit config, which has its own risks (network dependency, rate limits during setup). So OpenClaw saves what you give it and lets the provider reject it at call time. The key is saved. The error only surfaces when you try to make a call using that key. At that point you get a provider authentication error, which may say “401 Unauthorized” or “Invalid API key” or sometimes just a generic request failure. If you are debugging something else at the time, you may not immediately connect the error to a key typo.

What breaks: Every tool call fails. The agent responds to conversational messages normally. It does not need an API key to think. But the moment it tries to use a tool (search, memory, file read via provider, anything that calls an external service using that key), it fails. The failure message depends on the provider and does not always say “your API key is wrong.” Time wasted debugging the tool instead of the credential.

List all API keys configured in my openclaw.json. Do not show me the key values. Just show me which providers have keys configured, whether each key looks structurally valid (correct length and format for that provider), and whether any keys are returning authentication errors when called. Then run a quick test call to each configured provider and tell me which ones succeed and which fail.

Field 7: compaction.model

What it is: When OpenClaw compacts a session (summarizes older messages to free up context space), it uses an AI model to write the summaries. compaction.model specifies which model to use for this. If not set, OpenClaw uses whatever model it can reach, which defaults to your primary model.

The default: Compaction uses your primary model. If your primary is an expensive API model (like claude-opus-4 or similar), every compaction event runs that model against your entire conversation history to write summaries. Compaction fires silently, in the background, whenever the context threshold is reached. You do not see it happening.

What breaks: You see unexpected charges on your API bill for calls you do not remember making. If you use an expensive primary model and run long sessions, compaction can add significant cost. A 100,000-token session that compacts twice is two additional full-context API calls against your primary model. At expensive tier pricing, that adds up quickly.

To put numbers to it: at Anthropic pricing for Claude Sonnet as of March 2026, a 100,000-token context call costs roughly $0.30 in input tokens alone. If compaction fires twice in a session and uses the same model, that is $0.60 in background calls you did not initiate. Across 10 sessions per week, that is $6 per week or about $26 per month in compaction costs alone, in addition to your normal conversation costs. Switching compaction to a local Ollama model brings that to zero. A local model like llama3.1:8b or phi4 can write session summaries at zero API cost.

What is the current value of compaction.model in my config? What model is being used for compaction right now? Is that model more expensive than a local alternative I could use instead? If I have Ollama set up with any models, which one would be the best cost-free replacement for compaction?

Run the full check in one pass

If you want to check all seven fields at once rather than section by section, use this:

Run a full config audit for me. Check and report the current value of each of the following fields: (1) gateway.bind: is it 127.0.0.1 or 0.0.0.0, and what does that mean for my exposure? (2) agents.defaults.tools.exec.security: what is it set to and is it appropriate for production? (3) agents.defaults.fallbackModels: is a fallback chain set, and if so, what is it? (4) agents.defaults.contextTokens: what is it set to and how does it compare to my primary model’s max context window? (5) memory scope: are scopes configured in my memory plugin? (6) All API keys: do a test call to each configured provider and tell me which succeed and which fail. (7) compaction.model: what model is being used for compaction and is it the cheapest available option?

For each field, tell me: current value, whether it is a concern, and what to change it to if so.

Your agent will run through all seven and give you a prioritized list of what needs attention. Fix them in order: gateway.bind and exec security first (security), then fallback model and compaction model (cost), then contextTokens (session quality), then memory scope (context hygiene), then API keys (reliability).

Applying all fixes in order

If the full check above surfaced issues across multiple fields, here is the sequence that minimizes disruption. Fixing in the wrong order can cause a second lockout. For example: if you change exec security before confirming gateway.bind is locked down, you have improved your security but not closed the primary exposure. Fix in this order:

This is the outermost layer. Locking the gateway to loopback means the gateway itself cannot be reached from outside. Do this before anything else.

Check my current gateway.bind value. If it is not 127.0.0.1, tell me: (1) will changing it break any of my paired mobile nodes or external integrations, and (2) what is the safest way to change it given my current setup. If I need SSH tunneling set up first, tell me that now before I change the bind address.

Once the gateway is locked to loopback, exec security is the next layer. Setting it to allowlist now means that even if something later misconfigures the gateway, the blast radius for exec calls is bounded by your allowlist.

Set agents.defaults.tools.exec.security to allowlist. For allowedCommands, start with this list: ls, cat, grep, pwd, git, curl, python3, node. (If you do not use git through your agent, you can leave it out. The agent will let you know if any scheduled tasks need it.) Tell me if any of my current scheduled tasks or automations need additional commands beyond that list, and if so, which ones to add. Then validate the config and apply it.

Restart the gateway after applying both gateway.bind and exec security changes. You can apply both before the restart if you want to do it in one operation.

These are cost controls. Apply them in the same config change as the security fixes if you want a single restart.

Do the following in a single config change: (1) Set agents.defaults.fallbackModels to my cheapest available model (if I have Ollama running, use the local model; otherwise use the cheapest API model I have configured). (2) Set compaction.model to the same cheapest model. Show me the config changes before applying them, and then validate and restart.

contextTokens does not take effect in a running session. Apply this, restart, and then start a new session with /new to pick up the new value.

What is the maximum context window for my current primary model? Set agents.defaults.contextTokens to 85% of that value. Validate and restart. After the restart, I will need to start a new session with /new for this to take effect.

Do this after the restart so the config changes are confirmed stable before you touch credentials.

Test all configured API keys right now. For each provider I have configured under models.providers, make a minimal test call and tell me whether it succeeds or fails. If any fail, tell me which key looks wrong and what the provider’s expected key format is so I can identify the typo.

This one is optional in the sense that it does not affect security or API cost. But if you run multiple projects through the same agent, scope configuration is the difference between a memory system that helps you and one that actively confuses you.

Do I have a memory plugin configured? If yes, are scopes set up? If no scopes are set, tell me: based on how I typically use you (look at our conversation history for patterns), what memory scopes would make sense for my setup? Give me two or three scope names and what kind of memories each one would hold, then tell me how to configure them.

FAQ: OpenClaw setup and missing fields

The documentation is accurate: OpenClaw runs without them. What the documentation does not spell out is that “runs without them” means “runs with the development defaults,” and development defaults optimize for easy setup, not for production safety or cost control. This is true of most developer tools. The assumption is that operators who care about security and cost will configure those fields. The documentation does not make it obvious which defaults are dangerous versus which are fine to leave. This article does.

For most of these, yes. gateway.bind, exec security, fallbackModels, contextTokens, and compaction.model all require a gateway restart to take effect. Memory scope changes take effect when the memory plugin reinitializes, which for most plugins happens at session start without a gateway restart. API key changes in models.providers take effect on the next API call, also without a restart. The safe pattern: always validate after any change (ask your agent: “Validate my current config and tell me if there are any errors”), always restart after any gateway-level setting, and always start a /new session to ensure your running session picks up the updated contextTokens value.

127.0.0.1 is loopback only, which means it only accepts connections from the same machine the gateway is running on. If you were connecting from your phone via a URL pointing to your server’s IP, that connection is now blocked. The fix is SSH tunneling: forward a local port on your phone or laptop to the gateway’s loopback port on the server over an encrypted SSH connection. This gives you remote access to a loopback-only gateway without exposing it. The linked article at the bottom of this page covers SSH tunnel setup for OpenClaw specifically.

Check the gateway access logs. Ask your agent: “Show me the last 200 lines of the OpenClaw gateway log. Look for any requests that came from IP addresses other than 127.0.0.1 or my known access IPs. Tell me if there are any requests I would not have made myself.” On Linux, journalctl -u openclaw-gateway --since "7 days ago" --no-pager | grep -v "127.0.0.1" pulls all non-loopback access in the past week. If the log shows connections from unknown IPs and your exec security was set to full, treat your API keys as compromised and rotate them.

It depends entirely on who can reach your gateway. If gateway.bind is set to 127.0.0.1 (loopback only) and your machine is not shared with other users, exec at full is a workable risk. If your gateway is reachable from outside your machine, exec at full combined with no gateway authentication is a serious exposure. Fix gateway.bind first. Once only you can reach the gateway, exec at full becomes a much smaller risk, though allowlist mode is still better practice for anything important.

Yes. Set up a cron job that runs a config health check on a schedule. Ask your agent: “Create a cron job that runs every Monday at 9am and checks the following: gateway.bind value, exec security mode, and whether all API keys are returning valid responses. Send the results to me via Telegram (or whichever channel you have configured).” This turns a manual check into a recurring automated one. The OpenClaw cron system can run the check and deliver the report without you doing anything.

Yes, each instance has its own config file and needs to be checked independently. The riskiest setup is multiple instances where only one was hardened and the others were left at defaults. If you have more than one instance, run the full check blockquote above on each one. The security and cost risks multiply with each unreviewed instance.

Go Deeper