Run Claude Code Agents on a Schedule in the Cloud

You use Claude Code locally. It reviews code, writes tests, debugs problems. You close the laptop and the work stops.

What if it kept going?

My Agent Tasks is a new feature in Open Source Cloud (OSC) that lets you schedule Claude Code to run autonomously in the cloud, on your repositories, on a cron schedule, without your machine being on. Daily code reviews, automated health checks, weekly dependency audits, scheduled deployment reports. You define the task once. The agent does the work.

I built this on top of claude-runner, an open source service I developed that runs headless Claude Code sessions as one-shot jobs in containers. The scheduling layer, credentials management, and web UI shipped on April 14, 2026 as My Agent Tasks in the OSC console.

Everything is open source. No proprietary agent runtime, no black-box infrastructure.

What this is for

Claude Code in your IDE is interactive: you type, it responds, you iterate. That model is great for active development sessions. It breaks down for anything that should happen automatically.

Consider the tasks you actually want running on a schedule:

• Review the src/ directory for new security issues every morning
• Check that deployed services are healthy after each release
• Generate a weekly summary of what changed and why
• Update a docs file whenever the codebase drifts from it
• Post a Slack report after a nightly batch job completes

None of these need you at the keyboard. They need an agent with access to your code, the right prompt, and a timer.

My Agent Tasks is that timer, attached to that agent, running in the cloud.

Prerequisites

Before you start, you need:

• An OSC account on a paid plan (Personal, Professional, or Business). The free tier does not include scheduled tasks.
• A git repository, either public or private (HTTPS URL required)
• An Anthropic API key

Step 1: Get your authentication credentials

Get an API key from console.anthropic.com. Navigate to API Keys, create a new key, and copy the value.

This is standard Anthropic API billing: you pay per token consumed by each task run.

Step 2: Navigate to My Agent Tasks

Open https://app.osaas.io/dashboard/agent-tasks.

The first time you visit, OSC prompts you to configure your credentials. Enter your token (OAuth or API key) and click Save. The credentials are stored in Kubernetes Secrets on the platform, never exposed in API responses or logs.

Once saved, you land on the task list, which is empty until you create your first task.

Step 3: Create your first task

Click "Create Task". You will see a form with several fields.

Walk through them:

Name

A short identifier with no spaces. This becomes part of the job name in the system. Example: code-review, daily-health, docs-sync.

Description

A plain English description of what this task does. For your own reference.

Prompt

This is the instruction Claude receives. Write it the same way you would write a CLAUDE.md prompt or a Claude Code session opener. Be specific about what you want done and where results should go.

Example prompt for a code review task:

Review the code in src/ for potential bugs, security issues, and code quality problems.
Focus on: unhandled errors, SQL injection, authentication flaws, and logic errors.
Write a summary of findings to review.md. If no issues are found, write "No issues found" with the date.

Source URL

The HTTPS URL to your git repository. Supports a branch suffix with #:

https://github.com/myorg/myrepo
https://github.com/myorg/myrepo#main
https://github.com/myorg/myrepo#staging

Schedule

OSC provides presets for common schedules:

Preset	Cron expression
Every 15 minutes	*/15 * * * *
Hourly	0 * * * *
Daily at 9am	0 9 * * *
Weekdays at 9am	0 9 * * 1-5
Weekly Monday at 9am	0 9 * * 1

You can also enter any valid cron expression directly for custom schedules.

Advanced settings

Expand the advanced panel for these options:

Model

Defaults to claude-sonnet-4-5-20250514. Change this if you want a different Claude version. Use a less capable model for simple tasks to reduce token usage.

Max Turns

Defaults to 25. This is how many back-and-forth steps Claude can take in a single run. For straightforward tasks like "generate a report", 10 is plenty. For complex tasks involving multiple files and tool calls, raise it. Higher values cost more tokens.

Allowed Tools / Disallowed Tools

By default Claude has access to all standard tools: file read/write, bash execution, web fetch. Restrict this for safety.

For read-only analysis runs, add Edit,Write,Bash to Disallowed Tools. The agent can read files and produce output but cannot modify anything.

For tasks that only need to inspect code:

• DisallowedTools: Edit,Write,Bash

For tasks that should write files but not run code:

• DisallowedTools: Bash

Sub Path

If your repository is a monorepo, set this to the subdirectory where Claude should work. Example: packages/backend or apps/web. Claude's working directory will be set to this path.

Git Token

For private repositories, provide a GitHub Personal Access Token (or equivalent). Stored as a Kubernetes Secret.

To reference a stored secret instead of a raw token value:

{{secrets.mygithubtoken}}

See the section on the CLI below for how to store secrets this way.

OSC Access Token

Required only if your task needs to manage OSC services from within the agent session. For example, a task that provisions a new service instance or queries the catalog. This enables MCP integration from within the task. Leave empty for tasks that only touch your repository.

Step 4: Run and monitor

After saving, your task appears in the list with its schedule and status.

Run Now: Triggers an immediate execution without waiting for the next scheduled time. Useful for testing your task before relying on the schedule.

Last Run / Next Run: Shows when the task last executed and when it is scheduled to run next. The scheduler polls every 60 seconds, so the next run timestamp is accurate within a minute.

Edit / Delete: Standard task management. Editing a task takes effect on the next scheduled run.

To see what happened during a run, check the logs for the underlying claude-runner job instance. You can find these in the OSC service catalog under the birme-claude-runner service, or query via the CLI.

Using the CLI

If you prefer to manage tasks from the terminal, the OSC CLI exposes the underlying claude-runner service directly.

Install and authenticate:

export OSC_ACCESS_TOKEN=<your-osc-token>

Create a job:

npx -y @osaas/cli create birme-claude-runner codereview \
  -o AnthropicApiKey="{{secrets.anthropicapikey}}" \
  -o SourceUrl="https://github.com/myorg/myrepo" \
  -o Prompt="Review the code in src/ for potential bugs and security issues. Write a summary report to review.md." \
  -o MaxTurns="10"

The {{secrets.name}} syntax tells the runner to pull the value from your stored secrets at runtime, rather than embedding credentials in plain text in the job definition.

Store a secret first using the web console or via the CLI. Then reference it with {{secrets.anthropicapikey}} in any job option. This applies to git tokens, API keys, Slack webhook URLs, and any other sensitive value you need injected at runtime.

Using MCP tools for an AI-native workflow

If you have the OSC MCP server connected to Claude or another MCP-compatible tool, you can manage agent tasks through natural language:

Create a daily task called sync-report that runs every weekday at 9am.
It should clone https://github.com/myorg/myrepo and run:
"Generate a daily standup summary from git log since yesterday.
Write it to standup.md."

List my agent tasks

Run my code-review task now

The MCP server maps these requests to dedicated agent task tools: setup-agent, create-agent-task, list-agent-tasks, run-agent-task, and delete-agent-task. You are managing cloud infrastructure through conversation, without touching the UI or CLI at all.

The OSC MCP endpoint is https://mcp.osaas.io/mcp. Connect it from Claude Desktop, Cursor, or any MCP-compatible client.

Injecting environment variables with a parameter store

Some tasks need credentials beyond the git token and Claude auth: a Slack API token, a webhook URL, a database connection string. You do not want these hardcoded in your prompt or repository. OSC solves this with a parameter store (the Application Config Service).

When you set the Config Service field on a task, Claude Runner loads all key-value pairs from that parameter store and injects them as environment variables before the session starts. Your prompt can then reference them naturally, and any Bash commands Claude runs will have access to them.

Setting it up

1. Create a parameter store

You can do this through the OSC web console, the CLI, or via MCP. Using the CLI:

npx -y @osaas/cli create eyevinn-app-config-svc myagentconfig \
  -o RedisUrl="<your-valkey-url>"

Or use the setup-parameter-store MCP tool which creates both the Valkey instance and the config service in one step.

2. Add your environment variables

Store the keys your task needs. For example, a Slack token:

curl -X PUT "https://<your-config-svc-url>/api/v1/config/EYEVINN_SLACK_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"value": "xoxb-your-slack-bot-token"}'

Add as many keys as you need. Each one becomes an environment variable in the runner container.

3. Reference it in your task

When creating or editing a task, set the Config Service field to the name of your parameter store (e.g., myagentconfig). You also need an OSC Access Token set, since the runner uses it to read the parameter store at startup.

Now your prompt can reference the injected variables. Here is a real example I use for scheduled deployment updates with Slack notifications:

Prompt:

Restart myapps intercom, mediaconvert, analytics, opensubtitlesite so it
fetches latest code. Post to slack channel #osaas-agents using the
environment variable EYEVINN_SLACK_TOKEN when done.

The agent restarts the apps using OSC MCP tools, then posts a summary to Slack using the token that was injected from the parameter store. No credentials in the prompt, no secrets in the repository.

This pattern works for any external service: post to Discord, update a Notion page, trigger a webhook, write to a database. Store the credentials in the parameter store, reference them in the prompt by environment variable name.

Practical use cases

Here are four patterns that work well with My Agent Tasks.

Automated code review

Schedule: Weekdays at 7am, before standup

Max Turns: 15

Prompt:

Review the diff since yesterday (use git log and git diff). Look for:
- Obvious bugs or unhandled edge cases
- Missing error handling
- Security issues (injection, auth flaws, hardcoded secrets)
Write a concise review to daily-review.md with severity labels: INFO, WARNING, CRITICAL.

This gives your team a morning code review without a human having to do it.

Scheduled deployment health check

Schedule: Every hour

DisallowedTools: Edit,Write

OSC Access Token: set

Prompt:

Check the status of my OSC services using the available MCP tools.
For each service that is not healthy, list the service name and error.
Output the result to stdout as a JSON object with keys: healthy, degraded, failed.

With an OSC Access Token set, the agent can call OSC MCP tools from inside the task to query your live service instances.

Daily dependency audit

Schedule: Weekly Monday at 8am

Max Turns: 20

Prompt:

Run npm audit (or equivalent for this project) and check package.json for outdated dependencies.
Produce a report in audit.md listing: critical vulnerabilities, high vulnerabilities, and packages more than 2 major versions behind.
For each critical finding, suggest the upgrade command.

Read-only analysis with restricted tools

For tasks where you want analysis only with no risk of the agent modifying your codebase:

DisallowedTools: Edit,Write,Bash

Prompt:

Analyze the TypeScript types in src/types/ and identify any patterns that suggest missing null checks, incorrect return types, or overly broad any usage.
Output a type safety summary to stdout listing each finding with file path and line number.

With Bash disabled and Edit/Write disabled, the agent reads files and reasons about them. Nothing runs. Nothing changes. Safe to run against production codebases.

How it works under the hood

The claude-runner service clones your repository into an ephemeral container, then runs Claude Code non-interactively with your prompt and configuration. The container has a full file system, network access (controlled by your tool settings), and the Claude Code runtime.

The scheduler in OSC checks tasks every 60 seconds and spawns a new job container when a task is due. Each run is isolated: previous run state does not carry over unless your task explicitly reads output files committed back to the repo.

Credentials are stored as Kubernetes Secrets in the platform namespace. They are never returned in API responses, never logged, and never included in job definitions as plain text.

The runner, the scheduler, and the platform infrastructure are all open source. No proprietary agent runtime sits between you and Claude.

Preparing your repository for agent tasks

The quality of the agent's output depends heavily on the context it has. Before relying on scheduled tasks, invest a few minutes in your repository's context files.

Add a CLAUDE.md file

This is the most important thing you can do. CLAUDE.md is loaded by Claude Code at the start of every session. Put in it:

• What this project does (one paragraph)
• Tech stack and key dependencies
• How to run tests
• Common patterns and conventions specific to your codebase
• Things Claude should NOT do (e.g., "never commit directly to main")

# my-api

A REST API built with Node.js, Express, and Postgres.

## Testing
npm test - runs the full test suite
npm run test:unit - unit tests only

## Conventions
- All errors must be wrapped in AppError class
- Never use any TypeScript type
- Database queries go in src/db/, never inline in routes

Add .claude/settings.json for tool restrictions

You can set default tool restrictions at the repo level rather than configuring them per task:

{
  "disallowedTools": ["Bash"]
}

This acts as a safety baseline for all agent tasks targeting this repository.

Use sub-path for monorepos

If your repo has multiple packages, set the Sub Path field to direct the agent to the relevant package. The agent's working directory will be scoped to that path.

This is agentic engineering

There is a shift happening from vibe coding (AI in your IDE, you direct everything interactively) to agentic engineering, where agents run autonomously on schedules, performing real work independently.

The difference is not the capability of the model. It is where the agent lives and when it runs. An agent that only runs when you are at the keyboard is a powerful tool. An agent that runs on a schedule, in the cloud, with access to your repositories and infrastructure, is a colleague.

My Agent Tasks makes the second thing practical to set up.

Every component that makes this work is open source: the claude-runner service, the web runners, the scheduler, the OSC platform itself. When you schedule an agent task on OSC, you are not locked into any proprietary runtime or vendor-specific agent format. You can inspect, modify, or self-host every layer.

Get started

The My Agent Tasks interface is at https://app.osaas.io/dashboard/agent-tasks.

Documentation is at https://docs.osaas.io.

If you want to talk to other developers building on OSC, the community Slack is at https://slack.osaas.io.

Start with a read-only task: pick a repository, set DisallowedTools to Edit,Write,Bash, write a prompt that produces a report file, and run it manually first. Once you have output you trust, turn on the schedule.

---

Open Source Cloud provides 200+ open source projects as managed services with native MCP integration. Every component is open source, zero vendor lock-in. Revenue is shared with the creators of the open source projects that power the platform.