Unattended AI Coding in Practice: A Guide to Long-Running Task Automation with Cloud Code

Can AI Coding Tools Run All Night?

Can AI coding tools run for extended periods without popping up manual confirmations, working independently through the night? The answer is yes — but it's definitely not as simple as flipping a "disable confirmations" switch.

Between the moment you go to sleep and the morning when you wake up to finished code, there isn't just a button — there's an entire engineering methodology. This article systematically breaks down how to achieve true unattended operation with Cloud Code and similar AI coding tools.

Why Do AI Coding Tools Keep Waiting for You to Press Enter?

Here's the real scenario most people face: a long-running task is halfway through, and the AI pops up a confirmation dialog for every single command, sitting there waiting for you. You want to sleep, but it's waiting for your Enter key — that's not unattended operation, that's pulling an all-nighter babysitting the AI.

Most people's first instinct is to look for a "disable all confirmations" switch. That's where the thinking goes wrong.

The Real Reason Confirmation Prompts Exist

AI coding tools like Cloud Code have evolved from simple code completion into systems with "Agentic Capability." These tools are built on Large Language Models (LLMs), but through Tool Use / Function Calling mechanisms, they've gained the ability to operate on real systems — reading and writing file systems, executing shell commands, calling APIs, managing version control, and more. This architecture is known as an "AI Agent," distinct from ordinary conversational models that only output text.

Precisely because Agents can produce real Side Effects, Cloud Code doesn't just output text — it can read and write files, run commands, install dependencies, interact with external systems, and even push code or invoke cloud services. Once it has the power to take real actions, there must be permission boundaries. Confirmation prompts aren't there to annoy you — they exist because the AI is about to perform an operation that affects a real system, and a human must make the final call.

Once you understand this, you'll stop looking for that "disable decisions" switch — because that switch itself is the wrong goal.

Core Insight: Unattended Doesn't Mean No Safety System

This is the most important insight in this entire article: the prerequisite for unattended operation is clearer safety boundaries.

The wrong mindset treats unattended operation as "I'm brave enough to turn off all protections." The mature engineering approach treats it as "I've drawn the boundaries extremely clearly and defined the rules in advance, so I'm confident letting it run on its own."

True automation isn't about losing control — it's about pre-solidifying control. The mental leap you need to make is: from "ask as you go" to "decide in advance."

• Typical usage: Ask as you go — stop at every operation and wait for your decision, red lights all along the pipeline
• Mature usage: Define before starting which operations are always allowed, which are never allowed, and which situations require a stop — then execute according to the rules, with no ad-hoc decisions needed throughout

Four Approaches to Reducing Confirmation Prompts

Approach 1: Pre-configure AI Tool Permissions

Write which commands can auto-execute, which files can be auto-written, and which directories must never be touched into configuration files ahead of time, rather than confirming each one at runtime.

Cloud Code's permission configuration lives in .cloud-settings.json and supports two core lists: an Allow list and a Deny list. This design embodies the Principle of Least Privilege from security engineering — granting only the minimum set of permissions necessary to complete a task, rather than leaving everything open by default.

Green light zone (safe to let the AI handle autonomously):

• Allow reading all project files
• Allow running pnpm lint, pnpm test, pnpm build, and other purely local validation commands
• Allow modifying files within the project source directory

Red line zone (must be blocked, no exceptions):

• Prohibit reading .env and any system secrets
• Prohibit executing high-risk commands like rm -rf, git push --force
• Prohibit triggering any deployment scripts

Secret file protection deserves special attention: when an LLM processes a task, it incorporates the content of files it reads into its Context Window for reasoning. Once the AI reads an .env file containing secrets, those secret strings appear in the model's reasoning context and may be logged or sent to the model provider's API endpoint. Even if the model itself won't "intentionally leak" secrets, this data flow already violates security compliance requirements.

You only need to write this checklist into the config file once, and it transforms how the entire project's collaboration works going forward. The AI flies freely in the green zone and can't take a single step past the red lines.

Approach 2: Build Isolated Environments with Git Worktree

Confine the AI's working scope to a specific directory or branch, and it can act more freely within those boundaries without constantly stopping to ask "can I touch this?"

Git Worktree is a native feature introduced in Git 2.5 that allows a single Git repository to maintain multiple independent working directories on the file system simultaneously, each corresponding to a different branch. Unlike cloning a repository, Worktrees share the same .git object database, making switching and creation extremely lightweight without consuming extra disk space for history. For Cloud Code, the most practical isolation approach is using Git Worktree to create an independent branch:

git worktree add ./project-ai-task feature/ai-task

This single command essentially creates a parallel universe for the AI. It writes code, modifies files, and runs commands in this isolated branch while the main branch remains completely unaffected.

The essence of isolation is: absolute freedom within boundaries. The AI can experiment boldly in the sandbox, but the main branch stays completely clean and untouched. Even if the AI breaks everything or crashes entirely, the blast radius is confined to the sandbox — the main branch remains unscathed.

This is why experienced engineers dare to kick off tasks that run all night — they're not just brave, they have hard boundaries.

Approach 3: Design Tasks as Non-Interactive

Give the AI a clear instruction, a well-defined scope, and acceptance criteria it can verify, then let it run to completion and report back — instead of waiting for your reply at every step.

The key to non-interactive tasks is the Golden Triangle, which is essentially the engineered application of Prompt Engineering in automation scenarios. When the AI encounters ambiguity or edge cases during execution, it faces two choices: stop and ask, or make assumptions and continue. The former breaks the automation flow; the latter may produce incorrect side effects. The Golden Triangle eliminates the main sources of ambiguity before the task even starts:

1. Clear objective: Which specific bug to fix, what feature to implement
2. Clear boundaries: Which files can be modified, which modules must not be touched
3. Clear acceptance criteria: Which tests must pass, what state constitutes "done"

All three sides are essential. Missing even one forces the AI to stop and ask you because it doesn't know how to decide. Next time it interrupts you, look back and check whether the triangle is complete.

Approach 4: Run High-Risk Long Tasks in Isolated Containers

You've seen people on social media saying "I kicked off a dozen tasks overnight and they were all done by morning."