Tag: Claude

Claude Cowork’s scheduling feature is one of the least-documented parts of the product, but it’s the most powerful. Understanding how it actually works — what triggers tasks, what Claude has access to when running them, and what the limitations are — changes how you design automation with it.

How Cowork Tasks Are Stored

Each Cowork task is a named, persistent instruction set saved locally in your Claude Desktop environment. The task contains: a name, a prompt (the full instruction Claude follows each run), a schedule, and optionally a working directory and a set of enabled tools. Tasks are stored in JSON format under your Documents folder at ~/Documents/Claude/Scheduled/ alongside a scheduled-tasks.json index file.

What Triggers a Scheduled Task

Tasks run on cron-style schedules configured when you create the task. Common schedules include daily at a specific time, weekly on specific days, or on-demand (manual trigger only). When the scheduled time arrives, Claude Desktop wakes the Cowork runner, loads the task prompt, and executes it with the configured tools and MCP connections active.

Critical limitation: Claude Desktop must be running and your machine must be awake when the scheduled time fires. Cowork is not a cloud scheduler — it depends on the local process being live. If your machine is asleep or Claude Desktop is closed, the task is skipped for that run with no retry.

What Claude Has Access to During a Task Run

When a Cowork task runs, Claude has access to everything configured in your Claude Desktop environment at that moment: all active MCP servers (Notion, Gmail, Google Drive, etc.), the Cowork bash VM for executing scripts and filesystem operations, any skill files mounted in the VM, and the working directory specified in the task config. It does not have access to the interactive chat thread — the task runs in its own isolated context.

Task Memory: What Carries Over Between Runs

Nothing carries over automatically. Each task run is stateless — Claude starts fresh with only the task prompt as its context. If your task needs to know what happened last time (what was published, what changed, what errors occurred), you have to build that logging into the task itself. The standard pattern: at the end of each run, write a log entry to a Notion page or local file; at the start of the next run, read that log to pick up context.

This is why well-designed Cowork tasks always end with a Notion write and start with a Notion read.

How to Design a Reliable Cowork Task

Tasks that work well have four components: a clear single objective per task (do one thing, do it well), explicit context loading at the start (read the log, check what already exists), a defined success condition Claude can verify, and a logging step at the end that captures what ran and any errors. Tasks that try to do too many things in one run, or that assume Claude will remember previous runs without explicit context, fail inconsistently.

When to Move Tasks to GCP Instead

Cowork scheduling works well for tasks that need to run during your working day when your machine is on. For anything that needs to run at 3 AM, run on a strict schedule with zero missed executions, or process large amounts of data that would exhaust the local VM disk — those belong on GCP Cloud Run or a Compute Engine cron job, not Cowork. The architectural principle: Cowork for interactive-adjacent automation, GCP for always-on production pipelines.

Claude Cowork stops working for a small set of predictable reasons. This page covers the five most common failures, how to diagnose which one you’re hitting, and the exact fix for each.

Error 1: “useradd failed: exit status 12”

What it means: The Cowork VM’s internal disk (sessiondata.img) is full. No new sessions can be provisioned.

Fix: Quit Claude Desktop. Move sessiondata.img from %APPDATA%\Claude\vm_bundles\claudevm.bundle\ (Windows) or ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/ (macOS) to your Desktop. Relaunch Claude Desktop — it recreates a fresh image. Full walkthrough: Claude Cowork useradd Failed Error Fix.

Error 2: Scheduled Tasks Stop Running

What it means: Tasks that were running on schedule suddenly stop firing. Often appears as tasks last running a few days ago with no new entries.

Causes: Machine went to sleep, Claude Desktop was quit, or the local runner process died. Cowork tasks require Claude Desktop to be open and running on an active machine. They are not fully cloud-hosted — they depend on the local Cowork environment being live.

Fix: Reopen Claude Desktop and manually trigger one task to verify it runs. For tasks that need to run reliably without the machine being awake, move them to a GCP Cloud Run cron job or a cloud VM instead of Cowork’s local scheduler.

Error 3: MCP Tools Not Available in Cowork

What it means: Cowork tasks can’t access Notion, Gmail, or other connected services that work fine in Chat.

Fix: MCP servers must be configured in claude_desktop_config.json — the same config file Claude Desktop uses. If an MCP server appears in Chat but not in Cowork, verify it’s listed in the desktop config, not just the web interface. Restart Claude Desktop after any config changes.

Error 4: File Access Denied or Path Not Found

What it means: A Cowork task fails trying to read or write a file that should be accessible.

Fix: Cowork’s VM mounts specific directories from your machine. If the file is outside a mounted path, Cowork can’t reach it. Check that the file path is within your configured working directories. On Windows, path separator issues (\ vs /) inside the Linux VM can also cause this — use forward slashes or escape backslashes in task prompts.

Error 5: Tasks Run but Produce Wrong Output

What it means: Cowork is running but the results are stale, wrong, or missing context from previous runs.

Fix: Cowork tasks don’t have memory of previous runs by default. If your task depends on knowing what happened last time — what was published, what changed — you need to build that context explicitly into the task prompt, typically by reading a log from Notion or a local file at the start of each run. The task prompt is the only persistent instruction; Claude doesn’t remember prior task outputs.

Anthropic now offers two distinct modes of working with Claude — the familiar chat interface and Cowork, a persistent task and agent environment. They look similar but serve fundamentally different purposes. Using the wrong one creates friction; knowing which to reach for first saves significant time.

What Cowork Actually Is

Cowork is a persistent agent environment inside Claude Desktop. It gives Claude access to your local filesystem, a sandboxed Linux VM with bash execution, your installed MCP servers, and a scheduler. Tasks you set up in Cowork can run on a schedule — daily, weekly, whenever you trigger them — without you being in the conversation. Claude operates autonomously against your instructions until the task is done.

What Claude Chat Actually Is

Claude Chat (claude.ai or the Claude app) is a stateless, interactive conversation interface. Each session is fresh. Claude has no persistent memory across sessions beyond what you’ve configured in memory settings. It’s optimized for real-time back-and-forth: you ask, Claude responds, you refine. The bash environment in Chat (used for file operations and code execution) is sandboxed and resets between sessions.

Side-by-Side Comparison

When to Use Claude Chat

Chat is the right tool when you’re actively involved in the work — drafting, editing, analyzing, strategizing. If you need to go back and forth, refine an output, or make judgment calls mid-task, Chat’s interactive model is faster and more natural. It’s also better for any task that’s genuinely one-off: you do it once, you’re done, there’s nothing to schedule or automate.

Chat also runs in the cloud, meaning it doesn’t compete with your machine’s other processes and doesn’t run into the local VM disk limitations that Cowork can hit with heavy workloads.

When to Use Cowork

Cowork shines for work that should happen without you: daily newsroom publishing, weekly SEO reports, nightly data syncs, any pipeline that follows the same steps every run. If you find yourself doing the same Claude Chat session more than twice a week, it’s a candidate for a Cowork task.

Cowork also makes sense for tasks that need direct access to files on your machine — reading from a local folder, processing downloads, interacting with local applications — since Chat requires you to explicitly upload files each session.

Known Cowork Limitation to Be Aware Of

Cowork runs on a local VM (the sessiondata.img file) with a fixed 8.5GB disk. Heavy users with many skills installed will periodically hit a disk-full error that prevents new sessions from launching. This is a known bug (GitHub #30751) with a manual workaround. See Claude Cowork useradd Failed Error: How to Fix It for the fix.

If every Cowork task is failing with useradd: cannot create directory /sessions/friendly-youthful-thompson or a similar error, your Cowork VM’s internal disk is full. This is not something you broke — it’s a known Anthropic bug that affects power users consistently. Here’s exactly what’s happening and how to fix it in under two minutes.

What’s Causing the Error

Cowork runs on a local VM with a fixed 8.5GB disk image called sessiondata.img. Every Cowork conversation creates a new directory under /sessions/<name>/ inside that VM and caches all your installed plugins and skills there. Those directories are never cleaned up automatically. Once the disk fills — roughly 80 sessions for light users, 40–50 sessions for users with many skills installed — every new task fails immediately with a useradd error. The session simply can’t be provisioned.

If you have 20+ skills installed (the Tygart Media stack runs 40+), you’ll hit the cap significantly faster than the average user.

The Fix: Move the Image File

The fix is the same on macOS and Windows: move sessiondata.img out of its location so Claude Desktop rebuilds it fresh on next launch.

Windows

Quit Claude Desktop completely. Open Run (Win + R), paste this path and press Enter:

Find sessiondata.img and move it to your Desktop as a backup. Relaunch Claude Desktop — it will recreate a fresh image automatically. Your first Cowork session after the reset may take slightly longer while plugins reinstall.

macOS

Quit Claude Desktop. In Finder, press Cmd + Shift + G and go to:

Move sessiondata.img to your Desktop. Relaunch Claude Desktop.

What Gets Wiped vs What’s Preserved

How Often Will You Need to Do This?

Until Anthropic ships automatic session cleanup, this is a recurring task. With a heavy skill load, plan on running the fix every 4–6 weeks or whenever you see the useradd error return. Setting a calendar reminder is the most reliable approach.

The Longer-Term Fix: Move Heavy Operations Off Cowork

The root cause is that Cowork was designed for lighter, conversational task automation — not running dozens of skills across many parallel sessions. If you’re running content pipelines, batch WordPress operations, or multi-step automation workflows, moving those operations to a GCP Cloud Run cron job or Compute Engine VM eliminates the local VM bottleneck entirely. Cowork’s local sandbox competes for your machine’s resources; GCP runs isolated, always-on, and never fills up your laptop’s disk.

Every few months, a new wave of “Claude 5 release date” searches spikes — and it makes sense. Anthropic moves fast, the gaps between major generations have been shortening, and early signals like Vertex AI log leaks have given the community something to speculate on. Here’s an honest breakdown of what’s confirmed, what’s leaked, and what the pattern suggests.

What’s Confirmed About Claude 5

As of April 2026, Anthropic has not officially announced Claude 5 by name in any public release notes, API documentation, or blog post. The company’s official model table shows the Claude 4.x family as current. No countdown page exists. No API model string beginning with claude-5 has appeared in public documentation.

What is confirmed: Anthropic is actively deprecating the original Claude 4.0 models (retiring June 15, 2026), recommending migration to Claude Sonnet 4.6 and Opus 4.6. This is a routine generational housekeeping move, not a Claude 5 announcement.

The Evidence For a Q2–Q3 2026 Release

The strongest early signal came in early February 2026, when a model identifier — claude-sonnet-5@20260203 — appeared briefly in Google Vertex AI error logs. Independent sources cross-verified the leak, and the codename “Fennec” circulated alongside claimed benchmark scores of around 80.9% on SWE-bench Verified, compared to Opus 4.6’s current scores.

Beyond the leak, the pattern is consistent: Anthropic has released a new major model generation roughly every 12–14 months since Claude 3. Claude 4.5 (the highest-capability 4.x model) reached 77.2% on SWE-bench Verified. A Claude 5 release that clearly exceeds that — not just marginally — would justify a major version bump and align with Anthropic’s stated commitment to releasing models that represent genuine capability leaps, not incremental updates.

Anthropic’s Release Pattern

A 12-month gap from the Claude 4 launch (May 2025) points to May–July 2026 as the earliest likely window. Anthropic has been explicit that they won’t rush a release — Claude 5 will need to clearly establish a new capability tier to justify the version number.

What Claude 5 Is Expected to Improve

Based on leaked benchmark data and Anthropic’s public research direction, the Claude 5 generation is expected to push forward on: extended thinking and multi-step reasoning (building on the chain-of-thought work in Claude 3.5+), larger context handling, improved agentic reliability for long-horizon tasks, and faster inference at the Sonnet tier. Pricing is expected to follow the established pattern — Claude 5 Sonnet likely priced at or below current Opus 4.6 rates while outperforming it on most tasks.

The Current Models Are Excellent — Don’t Wait

If you’re evaluating whether to build on Claude now or wait for Claude 5, the answer is build now. Claude Sonnet 4.6 and Opus 4.6 are capable, stable, and well-documented. The 4.x API will remain live well after Claude 5 launches — Anthropic maintains parallel model availability for enterprise predictability. Waiting costs you months of production time for a model that may arrive on an uncertain schedule.

For current model specs and API strings, see Claude API Model Strings — Complete Reference. For pricing on current models, see Claude AI Pricing: Every Plan Explained.

If you’re still running the original Claude Sonnet 4 or Opus 4 model strings in production, you have a hard deadline: June 15, 2026. After that date, calls to claude-sonnet-4-20250514 and claude-opus-4-20250514 will fail on the Anthropic API. Here’s exactly what’s being deprecated, what to migrate to, and what you’ll gain from upgrading.

What’s Being Deprecated

Anthropic is retiring the original Claude 4.0 model versions — the ones that shipped in May 2025. These are distinct from the 4.x versions released since. The specific API strings going offline:

These are not the latest Claude 4 models. If you’ve been on Anthropic’s recommended defaults, you’re likely already on 4.6. This deprecation primarily affects teams that pinned specific model version strings in their API calls rather than using the alias endpoints.

What to Migrate To

Anthropic’s recommendation is a direct version bump within the same model tier:

The 4.6 models are meaningful upgrades — not just version bumps. Claude Sonnet 4.6 ships with near-Opus-level performance on coding and document tasks, dramatically improved computer use capabilities, and a 1 million token context window in beta. Claude Opus 4.6 adds the same 1M context window alongside improvements to long-horizon reasoning and multi-step agentic work.

Why Anthropic Deprecates Models

Anthropic follows a predictable model lifecycle: new versions within a generation ship as upgrades, and older version strings are retired on a roughly 12-month timeline after a successor is available. This keeps the API surface clean and pushes users toward better-performing models. The deprecation of the original Claude 4.0 strings follows the same pattern as prior Claude 3 and 3.5 retirements.

For most API users, the migration is a one-line change — swap the model string. Prompting styles, tool use conventions, and JSON response formats are stable across 4.x generations. Anthropic has not announced breaking changes that would require prompt rewrites when moving from 4.0 to 4.6.

How This Fits the Claude 4 Generation Timeline

What If You Don’t Migrate Before June 15?

API calls to claude-sonnet-4-20250514 or claude-opus-4-20250514 after June 15, 2026 will return errors. There is no automatic failover to a newer model — the call simply fails. If you have any production systems, scheduled jobs, or automated pipelines using these version strings, audit them now. A global search for 20250514 in your codebase is the fastest way to find exposure.

What Comes After Claude 4.x

Claude 5 is expected in Q2-Q3 2026, based on Anthropic’s release cadence and early signals from Vertex AI deployment logs. As has been the pattern with prior generations, Claude 5’s mid-tier Sonnet model is expected to outperform the current Opus 4.6 on most benchmarks at a lower price point. No official announcement has been made as of April 2026.