The chat window just grew a night shift.
Visual Studio Code 1.137, released September 9, introduces Automations in preview: recurring agent tasks can run hourly, daily, weekly, or on demand. The same release adds experimental voice steering and lets a quick chat acquire a workspace without losing the current conversation.[1]
Those features look unrelated if you inventory buttons. They are one product direction if you inventory control: start work without sitting down, redirect it while it moves, and attach an initially abstract conversation to an actual codebase. The unit is no longer a chat response. It is a running session with a place, a clock, and consequences.
A schedule is an ignition circuit. It is not a roll cage.
Read the boring instructions. They are the product.
Microsoft's automation documentation says an automation can read files, run commands, and make changes according to the selected agent's permissions. It recommends reviewing the permission level, testing with Run now, checking each run's session, and accounting for recurring usage.[2]
The operational footnotes matter more than the calendar UI. Local schedules need the machine awake and an agent available; some require Agent Host, others a running VS Code window. A missed schedule may produce a catch-up run, but every missed occurrence is not guaranteed to replay. The same automation runs one session at a time. Disabling future runs does not stop one already moving.[2]
That means “hourly” is not a complete behavior contract. You need idempotency, a freshness check, a maximum age for catch-up work, and a stop path for the active session. Otherwise the first morning after a sleeping laptop becomes archaeology performed with write access.
Permissions belong above the prompt.
GitHub's September 9 enterprise control update makes the hierarchy explicit: administrators can classify shell commands, file reads and edits, and network domains as blocked, approval-required, or allowed. GitHub says those managed restrictions cannot be weakened by workspace settings, auto-approval, or saved approvals.[3]
That is the right shape even if you are one developer with one repository. A recurring prompt should not carry its own master key. Put immutable boundaries outside the prose: allowed paths, allowed commands, approved domains, secret handling, output destination, and a spending ceiling. Prompts explain intent. Policy limits capability.
Choose where the shift happens.
GitHub documents its cloud agent as a different execution surface from local IDE agent mode. The cloud route works in an ephemeral GitHub Actions-powered environment, can create branches and commits, and leaves work visible in commits and logs; local agent mode edits the developer's own environment.[4]
Neither route is automatically safer. The useful question is where the blast radius is easiest to name. A local docs sweep may need no network and no branch push. A cloud dependency update may deserve an isolated branch, a narrow token, tests, and a pull request—but no production credential. Select the execution surface from the capability envelope, not from whichever button is closest.
Make the morning receipt boring.
- Declare the route. Repository, branch strategy, file globs, commands, domains, and forbidden zones.
- Prove one manual lap. Run the exact task once before enabling recurrence.
- Budget the loop. Cap session length, tool calls, retries, and paid usage; define the stop condition.
- Make catch-up explicit. Decide whether stale work should skip, coalesce, or run once—not improvise.
- Leave evidence. Session link, diff, checks run, failures, cost/usage, and the human acceptance point.