OpenClaw: Phone and schedules

This is the fourth of eight OpenClaw pages. It covers the jobs that run while you are away, either on a schedule or from your phone, and then weighs each OpenClaw setting that trades safety for capability.

Wait until the first job has worked and you have looked at the folder yourself.

Schedules

Scheduled jobs are built in and switched on, but a new install has no jobs of yours. You can ask in the chat for a job that repeats, such as a short note written every morning. When a job has nowhere else to send its result, the result comes back to the chat that created it. The command for managing jobs is openclaw automations: list shows them, disable <jobId> pauses one, and remove <jobId> deletes one. Fixes shows how to check that the scheduler is running.

Keep scheduled jobs to writing files in the workspace at first, and do not let them send messages or spend money yet.

The computer has to stay on. The agent runs on your computer, so a job runs only while the computer is on and the Gateway is running. On Windows, if OpenClaw could not set up its startup task, it starts only after you log in.

Your phone

The phone never runs the agent; it only talks to the Gateway on your computer. There are two ways:

• A chat app. Telegram ships with OpenClaw, while WhatsApp, Signal, and others are add-ons. The Telegram page shows how to make a bot with @BotFather and give OpenClaw its token. Wait until after the first week.
• The OpenClaw phone app. The iPhone app needs iOS 26.2 or later, and Android is on Google Play. By default the Gateway only answers this computer, so the phone cannot reach it until you set up a private connection. The docs name Tailscale Serve or a password-protected home-network setting, but this guide could not confirm beginner steps for either. The phone pages say the Gateway should run on a Mac, Linux, or Windows through WSL2, which is the Windows Hub setup, not the PowerShell one in this guide.

Keep strangers out:

• Leave direct messages on pairing, the default. A new sender gets a one-time code, and the agent ignores them until you approve it with openclaw pairing approve <channel> <code>. Codes expire after 1 hour.
• Never set dmPolicy to open, because that lets anyone talk to an agent that can use your computer.
• Group chats default to an allow list, so leave it that way.

What you should see only you can message the agent, and your computer stays on while you use it.

Trade-offs: safety versus capability

Shell approvals. The setting tools.exec.mode decides whether the agent asks before running commands. With ask, it runs only commands on its allowed list and asks you about anything else, while full, the out-of-the-box value, runs commands on your real computer without asking. It covers commands only. The file tools never ask, which is why page 2 also keeps them inside the workspace with tools.fs.workspaceOnly.

• You gain: full lets a long job run straight through, with no stops for your yes.
• You risk: with full and the sandbox off, a mistake or a prompt injection hidden in a web page can run any command your account can run, and change or delete your files.
• Makes sense when: you are a beginner, or you have not turned the sandbox on, keep ask. Do not set full, and skip /elevated in the chat, because once the sandbox is on it moves commands back onto your real computer.

The sandbox. The setting agents.defaults.sandbox.mode is off out of the box, so commands run on your real computer. Setting it to all moves commands and file changes into a sandbox, which needs Docker or a similar tool. Avoid non-main for this, because it leaves your main chat on your real computer. By default the sandbox works in its own separate folder instead of your workspace.

• You gain: a mistake lands inside the sandbox instead of on your real files, so you can give the agent more freedom.
• You risk: this is more setup, with Docker to install and keep running. The OpenClaw docs also say the sandbox is "not a perfect security boundary," so it limits the damage rather than ruling it out.
• Makes sense when: you have the first hour behind you, you are comfortable with Docker, and you want to run longer or unattended jobs. It is not a first-hour step, which is why the install page leaves it off, and Advanced features shows how to turn it on.

The workspace folder. OpenClaw's workspace defaults to ~/.openclaw/workspace, and you could point it at a real folder instead. Either way, it is a starting place for commands, not a wall.

• You gain: pointing the workspace at real files lets the agent work on the documents you actually care about.
• You risk: with the sandbox off, a command can still reach any folder it names in full, and so can the file tools unless tools.fs.workspaceOnly is on. A workspace set to your user folder or Documents puts those files in easy reach, and the file tools can change anything inside the workspace without asking.
• Makes sense when: you want the agent on real files and you have a backed-up folder to give it, such as photos to rename, or copies you made in the workspace. Never point it at your whole user folder, Documents, or Desktop, and until you need real files, keep the default.

Chat apps and your phone. Telegram, other chat apps, and the phone app let you reach the agent while you are away, but the Gateway has to keep running on a computer that stays on. Direct messages default to pairing, and dmPolicy set to open lets anyone in.

• You gain: you can send jobs from anywhere and get the results on your phone.
• You risk: anyone who gets past pairing can give orders to an agent that can use your computer. A private connection for the phone app also opens the Gateway beyond this computer.
• Makes sense when: your first jobs have worked, pairing is on, and you have approved only your own code. Never set dmPolicy to open, and skip the phone app until you are confident setting up a private connection.

Scheduled jobs. Schedules are built in and switched on, and a job runs while the computer is on and the Gateway is running, whether or not you are watching.

• You gain: regular work, such as a short note written every morning, gets done without you.
• You risk: nobody is watching an unattended job, so a mistake repeats on every run until you notice it.
• Makes sense when: the job only writes files in the workspace. Do not let a scheduled job send messages or spend money until you have watched it run several times.

For the three questions behind this advice, see Safety versus capability.

Sources

All checked 14 November 2026.

• Schedules: https://docs.openclaw.ai/cron/
• openclaw automations and its list, disable, and remove sub-commands: https://docs.openclaw.ai/cli/cron and https://docs.openclaw.ai/automation/cron-jobs
• Windows startup task: https://docs.openclaw.ai/platforms/windows
• Telegram bot setup with @BotFather: https://docs.openclaw.ai/channels/telegram
• Phone apps: https://docs.openclaw.ai/platforms/ios and https://docs.openclaw.ai/platforms/android
• Pairing and allow lists: https://docs.openclaw.ai/gateway/security/access-control
• Sandbox modes, including all and non-main, and file tools in the sandbox: https://docs.openclaw.ai/gateway/sandboxing, https://docs.openclaw.ai/gateway/sandboxing/modes-scope-and-backend, and https://docs.openclaw.ai/gateway/sandboxing/supported-capability-matrix
• Shell approvals: https://docs.openclaw.ai/tools/exec and https://docs.openclaw.ai/tools/exec-approvals/
• File tools never ask, and tools.fs.workspaceOnly: https://docs.openclaw.ai/gateway/security/tool-permissions and https://docs.openclaw.ai/gateway/permission-modes
• Elevated mode: https://docs.openclaw.ai/tools/elevated
• Workspace is not a sandbox: https://docs.openclaw.ai/concepts/agent-workspace
• The sandbox settings for after the first hour: the safety chapter

Next

Continue to Eight jobs to try.