# What /insights Found After a Month of Claude Code as an Operations Agent

48 sessions, 286 hours, and a report whose scheduled-task example had three bugs. The fixes we shipped the same day, with a free playbook and templates to copy.

Author: J.A. Watte
Published: October 16, 2026
Source: https://jwatte.com/blog/claude-code-insights-operations-agent/

---

Most Claude Code advice assumes you're writing software. For the last month I've used it mostly for something else: running a small portfolio of business websites. A motel group's booking sites, two laundromats, a self-storage payment portal, a news site and this one. Deploys, a nightly indexing routine, browser work in Search Console and business profiles, and a steady stream of articles.

Then I ran `/insights`, the report that reads your recent sessions and tells you how you work. The [weekly insights habit](/blog/claude-code-insights-iteration-workflow/) explains the report itself. This post is what happened when I took its suggestions literally on the same day: what it got right, where its examples would have broken, and the fixes now running. Everything here is also in a free [operations playbook](/downloads/claude-code-operations-playbook.md) you can copy.

## What the month looked like

The report covered September 16 to October 16: 52 sessions, 48 of them analyzed, 286 hours and 643 messages. It counted about 4,250 shell commands and more than 2,900 browser actions, against far fewer file edits. That ratio is the honest summary. Claude was clicking through Search Console and business dashboards for me as often as it was writing code.

It rated 42 of 47 sessions as mostly or fully achieved. The misses had a pattern, and the report named it in three parts: safety checks blocking deploys I had already approved in chat, overnight jobs that died quietly when the machine slept, and file edits made with shell one-liners that mangled backslashes and dollar signs.

All three were fair. None of them was a model problem. They were operations problems, and they have operations fixes.

## Fix 1: the nightly routine became a skill

The nightly indexing run showed up in about 14 sessions. Each night I typed some version of "run the nightly submissions", and each night Claude re-read a long playbook to rebuild the procedure. It worked, with about 11 accepted requests a night until Google's quota said no. But rebuilding the procedure every night is where small mistakes come from.

A [skill](https://code.claude.com/docs/en/skills) fixes that. A file at `~/.claude/skills/<name>/SKILL.md` becomes `/name`, and whatever follows the name arrives as `$ARGUMENTS`. The report's sample skill was a fine start, but it referenced a ledger file that doesn't exist on my machine and steps that didn't match the real routine.

What worked better was a short skill that points at the playbook instead of copying it. The playbook keeps changing as Google's interface changes; a copy inside the skill would go stale. The skill holds only the order of operations: read the playbook and last night's run sheet, confirm which runner spends tonight, do the free work first, spend only after the quota gate, stop at the first refusal, write the result. Tonight's overrides ("put these four URLs first") ride in as arguments.

## Fix 2: the scheduled run, and the three bugs in the example

The report was right that a wake-up armed inside a chat session is fragile. One night the virtual machine slept for eleven hours and every in-session timer fired late. Its suggestion was to let the operating system start Claude Code non-interactively with `claude -p`, using a one-line `schtasks` command.

Taken literally, that line had three problems:

1. **It changed into a folder that doesn't exist** and wrote its log into a `logs` folder that didn't exist either. The task would have failed on its first night, quietly.
2. **The time was local.** The run has to start after a gate measured in UTC. On a machine set to Pacific time, 04:10 is 11:10 UTC, hours after the gate, so every following night's gate would slide later too. The daylight-saving change on November 1 moves the answer by another hour.
3. **The permission flag wouldn't do what it looked like.** The [docs for programmatic runs](https://code.claude.com/docs/en/headless) say that listing `Bash` in `--allowedTools` approves shell commands, except in a run that starts in auto mode, where a bare `Bash` entry is dropped and each command goes back to the classifier. My sessions start in auto mode. In a `-p` run nobody is there to answer, so the unattended job would have stalled on exactly the kind of block the report was trying to remove.

The working version uses a small wrapper script and a task registered with PowerShell:

```powershell
$action = New-ScheduledTaskAction `
  -Execute 'cmd.exe' `
  -Argument '/c C:\ops\run-nightly.cmd'
$trigger = New-ScheduledTaskTrigger `
  -Daily -At '23:40'
$limit = New-TimeSpan -Hours 3
$settings = New-ScheduledTaskSettingsSet `
  -WakeToRun -StartWhenAvailable `
  -ExecutionTimeLimit $limit `
  -MultipleInstances IgnoreNew
Register-ScheduledTask `
  -TaskName 'Nightly indexing' `
  -Action $action -Trigger $trigger `
  -Settings $settings
```

The wrapper creates its log folder, names the log by UTC date, starts in the folder whose memory the run needs, and calls:

```bat
claude -p "/nightly-indexing" ^
  --permission-mode dontAsk ^
  --permission-prompts none ^
  --allowedTools "Bash,Read,Edit,Write,Glob,Grep"
```

`dontAsk` runs only what the list allows and denies everything else, and `--permission-prompts none` tells Claude a denial is final instead of something to retry. The task can wake the machine, has a three-hour ceiling, and never starts a second copy. At 23:40 Pacific it starts just after the current gate, and after the clocks change it still starts after the gate.

One more thing the report couldn't know: a second machine also had a nightly job armed against the same quota. Two runners on one quota means refusals and a ledger that disagrees with itself. We turned the other one off and left a note beside its switch saying how to turn it back on.

## Fix 3: allow rules and a hook that actually exists

The report suggested pre-approving routine deploy commands and adding a hook that syntax-checks edited JavaScript. Both are good ideas. The sample hook called `node scripts/check-edited.js`, a script that didn't exist in my working folder. Installed as written, it would have failed after every single edit.

The fix was to write the script and point the hook at its absolute path. A [`PostToolUse` hook](https://code.claude.com/docs/en/hooks) runs after the tool, and exit code 2 shows its stderr to Claude, so a syntax error comes back as a message Claude acts on right away. The script exits 0 for anything that isn't a `.js`, `.mjs` or `.cjs` file, and for any failure in the checker itself, so a broken checker can never block an edit. We tested it with a file containing `const a = ;` and got the expected `SyntaxError` and exit 2 before trusting it.

The allow rules went into the user [settings file](https://code.claude.com/docs/en/settings), merged with what was already there. While in that file we noticed an API key sitting in its `env` block in plain text. Settings files aren't a vault; a key belongs in a file read at run time. The [hooks and approval fatigue post](/blog/claude-code-hooks-approval-fatigue/) covers more hook patterns.

## Fix 4: a deliverables list before the work starts

The report's best suggestion was the plainest one: "list the deliverables for this session with a one-line 'done when' for each. Work on them in order. Deploy and verify each one before moving on." My sessions really do bundle five unrelated jobs, and the fifth one is the one that gets lost.

"Done when" has to name a fact you can check: the URL returns 200 and the commit is on main, or the run passes and the fix is installed. "Deploy the article" isn't one. The same afternoon the list held a release promotion, a policy change, the scheduled run, the settings, an article and this post, and each line closed with evidence beside it.

When a session runs long, the rule is to stop and write a resume kit to memory instead of starting another item: what's done with its evidence, what remains with the exact next command, what's still running and where its log is. Claude Code's [auto memory](https://code.claude.com/docs/en/memory) loads only the first 200 lines or 25 KB of its index, so the index stays short and points at detail files.

## What the report couldn't see

Some of the most useful lessons came from the same afternoon's work, after the report was written.

**Read the queue before adding to it.** I asked for a month of LinkedIn posts promoting recent articles. Before scheduling, the composer showed 58 posts already queued by an earlier session. Six of my drafts would have repeated articles already on the schedule, and some days would have carried three posts. We dropped one, rewrote five, and scheduled only on days with at most one existing post.

**Guard the irreversible click.** One coordinate click landed on a shifting feed and opened someone's photo instead of the post window. Nothing was posted, and we checked the account's activity to be sure. After that, every step found its element by role and text, and a small script read the date, time, opening words, length and link back from the page before pressing Schedule. If anything differed it threw an error, which stops the batch before the click.

**Small batches when safety checks are intermittent.** The safety check refused multi-post batches and sometimes single ones. One post per batch got 33 of 37 scheduled; after two refusals in a row we stopped and saved the last four to memory. Retrying a blocked action until it slips through isn't a workflow.

**Copies drift.** A desktop software update failed on a security gate saying owner acceptance was needed. Nothing new had been flagged. The test environment's copy of the acceptance policy still had dates that expired the day before, while the owner's record ran another three weeks. The fix wasn't to accept anything new. The update now syncs the test copy from the owner's record before it checks, never invents or extends an acceptance, and keeps a backup of what it replaced. If the gate still blocks after the sync, the message names the packages that need a decision.

**A job's report is a claim.** Background jobs wrote two of today's drafts. Their summaries were accurate, but I still checked the arithmetic in the cost table and fetched the pages behind the regulatory claims before deploying. One summary had dropped spaces from its numbers; the article itself was fine. You only know that by looking.

## Start this week

Run `/insights` and pick the single friction point it ranks first. Then:

- Put a deliverables list with "done when" lines at the top of your next long session.
- Turn your most repeated routine into a skill that points at your notes instead of copying them.
- Before scheduling anything unattended, check the paths, convert the time to your scheduler's zone, and set the permission mode on purpose.
- Test every hook and scheduled task once while you watch.

The [operations playbook](/downloads/claude-code-operations-playbook.md) has the templates: the deliverables prompt, the resume kit, a pointer skill, the Windows and Linux scheduler setups, the allow rules, the hook script, the browser guard checklist and a status report prompt.

## Related reading

- [The weekly /insights iteration](/blog/claude-code-insights-iteration-workflow/) for how to read the report every week.
- [Hooks that remove approval fatigue](/blog/claude-code-hooks-approval-fatigue/) for more hook patterns.
- [Skills, rules and memory](/blog/claude-code-skills-rules-memory-deep-dive/) for where each kind of instruction belongs.
- [/loop versus /schedule](/blog/claude-code-loop-vs-schedule/) for in-session and remote scheduling.
- [The agent fleet org chart](/blog/claude-code-agent-fleet-org-chart/) for running several agents at once.

## Fact-check notes and sources

All usage figures come from my own `/insights` report generated October 16, 2026, covering September 16 to October 16. Tool behavior was checked against the documentation below on October 16, 2026, with Claude Code 2.1.301.

- **Skills:** [Claude Code skills](https://code.claude.com/docs/en/skills) (personal skills in `~/.claude/skills/<name>/SKILL.md`, `$ARGUMENTS`).
- **Non-interactive runs:** [Run Claude Code programmatically](https://code.claude.com/docs/en/headless) (`-p`, `--allowedTools`, the auto mode exception for a bare `Bash` entry, `dontAsk`, `--permission-prompts none` from v2.1.259).
- **Hooks:** [Hooks reference](https://code.claude.com/docs/en/hooks) (`PostToolUse`, matcher syntax, exit code 2 shows stderr to Claude).
- **Settings:** [Settings files and precedence](https://code.claude.com/docs/en/settings).
- **Memory:** [How Claude remembers your project](https://code.claude.com/docs/en/memory) (auto memory index loads the first 200 lines or 25 KB).
- **Windows scheduling:** [Register-ScheduledTask](https://learn.microsoft.com/en-us/powershell/module/scheduledtasks/register-scheduledtask) and [New-ScheduledTaskSettingsSet](https://learn.microsoft.com/en-us/powershell/module/scheduledtasks/new-scheduledtasksettingsset).
- **Linux scheduling:** [systemd.timer](https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html).

*This post describes my own setup and results; adapt paths, times and permissions to yours.*


---

Canonical HTML: https://jwatte.com/blog/claude-code-insights-operations-agent/
RSS: https://jwatte.com/feed.xml
JSON Feed: https://jwatte.com/feed.json
Hero image: https://jwatte.com/images/claude-code-insights-operations-agent.webp