Why Cowork Scheduled Tasks Stop Mid-Run and How to Recover

Recovery: Fix by Pattern

Permission Dialogs

Open your SKILL.md and audit every tool call.

Prohibited in scheduled runs:
- AskUserQuestion
- Read / Write / Edit   ← replace file I/O with bash cat/sed
- request_cowork_directory

Rewriting all file access as bash commands is the real fix.

# ❌ Read tool
# ✅ bash
cat /path/to/file.md
 
# ❌ Write tool
# ✅ bash heredoc
cat << 'EOF' > /path/to/output.mdx
article content
EOF
 
# ❌ Edit tool
# ✅ sed
sed -i 's/old_text/new_text/' /path/to/file

One nuance worth checking: the SKILL.md itself is often clean, while the scheduled task prompt that invokes it is the actual offender. Make sure the task body explicitly states that it runs the whole workflow autonomously and never calls AskUserQuestion.

Disk Exhaustion (ENOSPC)

# Staged cleanup
# 1. Drop other repositories
for DIR in /tmp/repos/*; do
  [ -d "$DIR" ] && rm -rf "$DIR" && echo "removed: $DIR"
done
 
# 2. Clear the npm cache
npm cache clean --force 2>/dev/null
 
# 3. Clear .next build caches
find /tmp -name ".next" -type d 2>/dev/null -exec rm -rf {} + 2>/dev/null
 
df /tmp --output=avail -m | tail -1

The structural fix is to remove npm install from the scheduled workflow entirely. With Next.js on Cloudflare Workers, committing and pushing the MDX is enough — CI handles the build. Narrow the flow down to "clone → write MDX → push" and a single run writes 41MB, measured (11MB of which is .git, using a --depth 1 shallow clone, completing in 2.8 seconds). Compared to a workflow that installs packages, that is an order of magnitude difference.

Git Lock Conflicts

WORK="/tmp/repos/your-repo"
 
# 1. Remove the lock
rm -f "$WORK/.git/index.lock"
 
# 2. Reset repository state
cd "$WORK"
git reset --hard HEAD
git clean -fd
 
# 3. Pull again
git pull --rebase origin main

If that does not clear it, delete and re-clone.

rm -rf "$WORK"
git clone --depth 1 "https://${GITHUB_TOKEN}@github.com/username/repo.git" "$WORK"

safe.directory Does Not Remove the Failure — It Delays It

This is the part I most want to pass along.

Reuse a working clone long enough and one morning you meet this:

fatal: detected dubious ownership in repository at '/tmp/repos/claudelab.net'
To add an exception for this directory, call:

	git config --global --add safe.directory /tmp/repos/claudelab.net

Git even hands you the fix, so adding safe.directory feels like the obvious move. I did exactly that, and then spent a long time confused.

Here is the environment, measured:

$ git --version
git version 2.34.1
 
$ stat -c '%U:%G %a' /tmp/repos/claudelab.net
nobody:nogroup 755
 
$ echo "dir_uid=$(stat -c '%u' /tmp/repos/claudelab.net)  my_uid=$(id -u)"
dir_uid=65534  my_uid=1222

The directory belongs to uid 65534 (nobody) with mode 755. We are uid 1222. There was never any write permission here.

So what does safe.directory actually buy you? Measured results:

Every read command passes with exit 0.

safe.directory suppresses the ownership check only. It does nothing to file permissions. Read-only operations are satisfied by the r-x bits in mode 755, so they succeed — and everything dies the moment a write is required.

The problem is not that the failure disappears. It is that discovery gets postponed.

• A Step 0 that verifies repository health with git status sails right through
• The actual failure lands at the end, when you try to commit the article you just wrote
• Every minute of work spent in between is thrown away

There is a worse branch. If your workflow does not check the exit code of git pull, the pull fails while the run keeps going against a tree that is days old. The error is right there in the output, but the shape of the log looks normal, so a morning skim will not catch it.

The operational rule I took from this is simple: do not reach for safe.directory in a scheduled task.

safe.directory is the right tool when the files really are yours but git cannot tell — mounted volumes, or ownership skew introduced by sudo.

What we have here is different: the files genuinely are not ours. The answer is not an exception, it is moving somewhere you can write. When you find a directory owned by another uid, do not repair it. Discard it and re-fetch somewhere writable. That was consistently the shortest path back.

The Other Trap: Stale Clones and Failures That Look Like Success

Three more failures that never raise an error. I have hit all of them in production.

The first is a reused clone going quietly stale. A persistent repository under /tmp/repos drifts within days. git pull appears to succeed, but your local article list is from last week and you end up reworking something you already improved. Running several sites in parallel makes this kind of mix-up easy. Candidate selection and state checks should run against content fetched in this run, not against a clone you have been carrying around.

# Avoid the stale clone; re-fetch somewhere writable
WORK="$HOME/repos/your-repo"   # if /tmp is owned by another uid, go under $HOME
if [ -d "$WORK/.git" ] && [ -w "$WORK/.git" ]; then
  cd "$WORK" && git fetch origin main && git reset --hard origin/main
else
  rm -rf "$WORK"
  git clone --depth 1 "https://${GITHUB_TOKEN}@github.com/username/repo.git" "$WORK"
fi

The second is a commit failing in silence while push reports success. Right after a clone, git identity may be unset; run git commit in that state and no commit is created. The following git push simply has nothing to send, so it exits successfully and the log looks clean. Pass identity explicitly, and judge the outcome by comparing local and remote hashes.

git -c user.email="you@example.com" -c user.name="Your Name" commit -m "..."
git push origin main
# Judge by hash equality, not by what got printed
LOCAL=$(git rev-parse HEAD)
REMOTE=$(git rev-parse origin/main)
[ "$LOCAL" = "$REMOTE" ] && echo "✅ landed" || echo "⛔ not landed — resend required"

The third is your own shell hiding the failure. Pipe stderr into head or tail to make it readable, and $? now reports the exit code of the last element of the pipeline. The command can fail while $? cheerfully reads 0.

I measured this against the same permission error:

$ touch /tmp/repos/claudelab.net/.probe 2>&1 | head -1 > /dev/null
$ echo "$?  ${PIPESTATUS[0]}"
0  1          # ← $? is 0. The real failure is PIPESTATUS[0]=1
 
$ touch /tmp/repos/claudelab.net/.probe 2>/dev/null
$ echo "$?"
1            # ← drop the pipe and you get the truth

set -e will not save you either. The pipeline's exit status is considered 0, so set -e never fires and the rest of the script runs on.

Two fixes: keep commands you branch on out of pipelines, or declare set -o pipefail (or read ${PIPESTATUS[0]}) when you must pipe.

set -o pipefail
touch "$WORK/.probe" 2>&1 | head -1 > /dev/null
echo "$?"   # → 1 (propagates correctly with pipefail)

Log dates hide the same class of failure. Build a log filename with a bare date and the host may be on UTC, so a run that is still "today" in Japan picks yesterday's filename and overwrites yesterday's log. Generate dates with an explicit timezone.

D="$(TZ=Asia/Tokyo date +%Y-%m-%d)"   # a bare date can point at yesterday in UTC

As you extend Cowork automation across more sites, the total volume of these quiet failures grows with it. I wrote up the broader operational design in Running 4 Sites with 600+ Articles on Autopilot Using Cowork.

Preflight: Settle on a Writable Root Before You Clone

Put the pieces together and an ordering problem appears.

I used to write these as "clone first, fix problems as they come." With that order, permission and space problems surface after the clone — or much later.

Flip it. Settle on a place you can write, then clone into it. The preflight does not return a boolean; it returns the path of a working root you can actually write to.

#!/usr/bin/env bash
set -uo pipefail
 
MIN_FREE_MB=500
 
# Find a writable working root and print its path
# Try candidates in order; take the first that qualifies
pick_work_root() {
  local root avail
  for root in /tmp/repos "$HOME/repos"; do
    mkdir -p "$root" 2>/dev/null || continue
 
    # 1. Can we actually write? (-w covers owner, mode, and mount state at once)
    [ -w "$root" ] || { echo "skip $root: not writable" >&2; continue; }
 
    # 2. Is there enough space?
    avail=$(df -m "$root" --output=avail 2>/dev/null | tail -1 | tr -d ' ')
    if [ "${avail:-0}" -lt "$MIN_FREE_MB" ]; then
      echo "skip $root: ${avail}MB < ${MIN_FREE_MB}MB" >&2
      continue
    fi
 
    echo "$root"   # ← emit the chosen path
    return 0
  done
  return 1
}
 
WORK_ROOT="$(pick_work_root)" || {
  echo "E_PERM_ROOT: no writable working root available"
  exit 20
}
echo "work_root=$WORK_ROOT (avail=$(df -m "$WORK_ROOT" --output=avail | tail -1 | tr -d ' ')MB)"

Decide clone reuse the same way — branch on "can I write to it," never on "does it exist."

NAME="your-repo"
WORK="$WORK_ROOT/$NAME"
REPO_URL="https://${GITHUB_TOKEN}@github.com/username/${NAME}.git"
 
if [ -d "$WORK/.git" ] && [ -w "$WORK/.git" ]; then
  # Reusable: sync to latest (fetch + reset, not pull)
  cd "$WORK"
  if ! git fetch origin main 2>/dev/null; then
    echo "fetch failed — recreating" >&2
    rm -rf "$WORK" 2>/dev/null
    git clone --depth 1 -q "$REPO_URL" "$WORK" || exit 21
  else
    git reset --hard origin/main --quiet
  fi
else
  # Not reusable: remove if we can, then re-fetch
  rm -rf "$WORK" 2>/dev/null
  git clone --depth 1 -q "$REPO_URL" "$WORK" || exit 21
fi
 
cd "$WORK" || exit 21
echo "head=$(git rev-parse --short HEAD)"

Three decisions worth explaining.

1. Let -w make the call. Comparing owner uids yourself is tempting and it is the wrong instinct. A stat uid comparison assumes "I own it, therefore I can write it," which gets the answer wrong for group-writable directories and for read-only mounts. The speed difference is not small either: across 1,000 checks, test -w took 11ms while a stat-based uid comparison took 3,748ms, since stat forks a process every time. -w wins on correctness and on cost.

2. -w alone is not always enough. A writable .git with an unwritable worktree is a real combination. Probe the path you are actually going to write to.

3. Prefer fetch + reset --hard over pull. pull carries merge and rebase failure paths, and a conflict can leave you waiting on input that never arrives. For a disposable clone with no local changes worth keeping, reset --hard origin/main gives you a predictable result.

The 500MB threshold has reasoning behind it. One shallow clone measured 41MB with 11MB of .git, so roughly 50MB per site including the article writes. My /tmp had 2,990MB free of 9,741MB, so even four sites at once come to about 200MB. 500MB gives roughly 2x headroom. Add npm install back into the workflow and this estimate collapses.

Structure Your Logs with Reason Codes

Each failure above has its own recovery path. A log that only says "failed" means tomorrow-morning-you repeats the entire investigation.

Collapse failures into reason codes and that decision takes seconds instead.

Splitting the table by auto-recoverability is the point. E_APPROVAL will recur forever until a human edits the SKILL.md. Mix it in with the others and you manufacture a false sense of safety: "it fails daily, but it always recovers."

Write logs as one key=value record per line so they stay machine-readable.

log_line() {
  local result="$1" reason="${2:-}" detail="${3:-}"
  printf '%s site=%s result=%s reason=%s detail="%s"\n' \
    "$(TZ=Asia/Tokyo date +%Y-%m-%dT%H:%M:%S%z)" \
    "${SITE:-unknown}" "$result" "${reason:-NONE}" "$detail" \
    >> "${LOG_DIR}/$(TZ=Asia/Tokyo date +%Y-%m-%d).txt"
}
 
# Usage
log_line SUCCESS
log_line FAILED E_PERM_ROOT "uid 65534 != $(id -u) at /tmp/repos"
log_line SKIPPED E_DISK "avail=180MB"

Reviewing 30 days is then a two-liner.

# Occurrences per reason code, most frequent first
grep -h -o 'reason=[A-Z_]*' "${LOG_DIR}"/2026-0[67]-*.txt \
  | sort | uniq -c | sort -rn
 
# How long has it been failing? (days with failures, most recent last)
grep -l 'result=FAILED' "${LOG_DIR}"/*.txt | sort | tail -14

Once I started aggregating, my priorities rearranged themselves. The high-count reason codes were mostly the ones already recovering on their own. The one that actually deserved my hands was E_APPROVAL — low count, zero auto-recovery. Working top-down by frequency would have had me fixing things in the wrong order.

The same thinking applies to the health of your MCP connectors, which I covered in Make Your Nightly MCP Connectors' Health Visible.

Prevention: Defensive Code for SKILL.md

Rolled into Step 0 of a SKILL.md, it looks like this. The ordering carries the weight: pick the writable root first, clone second.

set -uo pipefail
 
# 1. Clear leftovers (only where we can write)
[ -w "${WORK:-/nonexistent}/.git" ] && rm -f "$WORK/.git/index.lock" 2>/dev/null
 
# 2. Settle on a writable root (abort with E_PERM_ROOT if none)
WORK_ROOT="$(pick_work_root)" || { log_line FAILED E_PERM_ROOT "no writable root"; exit 20; }
 
# 3. Space check (free space progressively from other repositories)
FREE_MB=$(df -m "$WORK_ROOT" --output=avail | tail -1 | tr -d ' ')
if [ "${FREE_MB:-0}" -lt 500 ]; then
  for OTHER in "$WORK_ROOT"/*; do
    [ "$OTHER" != "$WORK" ] && rm -rf "$OTHER" 2>/dev/null
  done
  FREE_MB=$(df -m "$WORK_ROOT" --output=avail | tail -1 | tr -d ' ')
  [ "${FREE_MB:-0}" -lt 500 ] && { log_line FAILED E_DISK "avail=${FREE_MB}MB"; exit 22; }
fi
 
# 4. Sync if writable, re-fetch if not
# 5. Always inspect exit codes (never behind a pipe)

Building in "recovers by itself on the next run" from the start is the rule that holds up over months. And the one class of failure that cannot recover by itself — the permission dialog — has to be closed in how you write the SKILL.md, not in code.

For the wider design of automation across multiple MCPs, see Cowork Multi-MCP Orchestration in Practice. For first-pass triage focused specifically on /tmp permissions and disk space, see git clone Fails in Cowork Scheduled Tasks.

Checklist Before You Automate

Eight things I check before putting a task on a schedule.

1. Are Read / Write / Edit / AskUserQuestion gone from both the SKILL.md and the task prompt?
2. Does working-root selection happen before the clone?
3. Is the writable check done with -w, against the path you will actually write?
4. Are you avoiding safe.directory? (Owned by another uid means relocate, not repair.)
5. Are you using fetch + reset --hard instead of pull, and checking the exit code?
6. Are branch-critical commands kept out of pipelines (or is set -o pipefail declared)?
7. Do you pass -c user.email / -c user.name before committing, and judge success by hash equality?
8. Are log dates generated with TZ=Asia/Tokyo date?

Items 2, 4, and 6 are the ones this round of measurement made me reverse. None of them produce a symptom while things are working. The symptoms arrive during the hours nobody is watching.

Open your own SKILL.md and read just the first ten lines of Step 0. Is there a line that confirms you can write, before the clone happens? If not, that is where your next outage begins.