My Agent Tasks is a feature in the OSC web console that lets you create and schedule automated AI agent tasks that run on your behalf. Instead of having your own machine running an AI agent on a schedule, OSC handles the execution for you in the cloud.

• Create tasks with a natural language prompt that the agent will execute
• Choose between two agent runtimes: Claude Code (Anthropic) or Codex (OpenAI)
• Schedule tasks to run automatically (every 15 minutes, hourly, daily, weekdays, weekly)
• Optionally point tasks at a Git repository so the agent has access to your code
• Trigger tasks manually at any time with "Run Now"
• Manage tasks via the web console or MCP tools

• An OSC account on a paid plan (Personal, Professional, or Business)
• An API key for your chosen runtime (Anthropic or OpenAI)

OSC supports two agent runtimes. You select the runtime when configuring credentials and creating tasks.

The original OSC agent runtime. Runs tasks using Claude Code CLI from Anthropic.

Supported credentials (choose one):

Best suited for: Tasks that benefit from Claude's reasoning, code generation, and OSC platform integration via MCP.

A newer runtime that runs tasks using OpenAI Codex CLI.

Supported credentials:

Best suited for: Tasks where you prefer OpenAI models (such as o3, gpt-4.1), or workflows already built around the Codex CLI and AGENTS.md conventions.

Go to My Agent Tasks in the OSC web console.

The page includes an AI prompt bar at the top. You can type a natural language question or request (e.g. "Create a daily task that posts a Slack summary") and the inline AI assistant will help you manage your tasks without leaving the page. Suggested prompts based on your existing tasks are shown as clickable chips below the input.

The first time you open the page you are prompted to configure your agent credentials. The page shows an onboarding hero with starter template cards below the setup form, so you can pick a common task type before you even enter your credentials.

For Claude Runner, choose one of:

• Anthropic API Key — an sk-ant-... key from console.anthropic.com
• Claude OAuth Token — a token obtained via Claude's OAuth flow

Personal use only: Per Anthropic's Consumer Terms, Claude subscription (OAuth) tokens are for personal use only. For automated or business agent tasks, use an Anthropic API Key instead.

For Codex Runner, provide:

• OpenAI API Key — an sk-... key from platform.openai.com

Enter the credential and click Save. The credentials are stored securely and used to run your tasks.

When you paste a credential value into the field, the type is detected automatically from the key prefix (for example, sk-ant-api03-... is identified as an Anthropic API key and sk-... as an OpenAI API key). If the detected type matches the currently selected runtime, the credential type selector updates automatically. If the pasted value appears to belong to a different runtime, a warning is shown so you can confirm you have selected the correct one before saving.

Once credentials are configured, a status bar at the top of the page shows the credential type. From there you can:

• Reconfigure — click to expand the setup form inline and enter new credentials
• Remove — opens a confirmation modal to delete stored credentials

Starter templates: When you have no tasks yet, the page shows four built-in starter template cards. Click any card to open the Create Task modal with the prompt field pre-filled:

You can edit the pre-filled prompt before saving. Starter templates appear until you have created at least one task.

Click Create Task and fill in:

OSC Access Token — Reference mode:

When you select Reference, the selector shows two groups of secrets:

When you select a workspace secret, OSC copies its value into the runner's secure secret store and generates a {{secrets.NAME}} reference. The raw credential value is never exposed in the task definition or MCP arguments.

Advanced Settings (click "Advanced Settings" to expand):

Schedule type:

Tasks have two scheduling modes, controlled by the Schedule Type field:

Use the Manual type for tasks that should only run when explicitly triggered — for example, one-off data migrations, on-demand reports, or tasks that need human review before each run.

Schedule presets (cron tasks):

Schedule times are stored in UTC but displayed in your local timezone. When you select a preset or enter a custom cron expression, the modal shows a live preview of the human-readable schedule and the next scheduled run time in your local timezone.

Click Create to save the task.

Scheduling note: New cron tasks do not fire immediately on creation. The first execution occurs at the first scheduled cron slot that falls after the task was created. For example, a task created at 9:05 UTC with a daily 0 9 * * * schedule will first run the following day at 9:00 UTC.

Tasks run automatically on their schedule. You can also:

• Click the Refresh button at the top of the tasks table to reload the task list and see the latest run statuses
• Click the Run Now button on any task to trigger it immediately
• Check the Last Run and Next Run timestamps in the task table
• Click the Last Run status chip to open the run history for that task
• Edit or delete a task from the actions column

Token expiry warning: If the OSC Access Token used by one or more of your tasks is expiring within 7 days, a warning banner appears at the top of the Agent Tasks page listing the affected task names. Click Rotate token in the banner to go to your API settings and regenerate the token before it expires. Keeping the token current prevents future runs from failing with authentication errors.

The home dashboard shows a warning indicator on the Agent Tasks stat tile when one or more tasks have a failed last run status. The badge displays the count of failing tasks and links directly to the Agent Tasks page so you can investigate quickly.

Auto-disable on repeated failures: If a task fails 5 times in a row, OSC automatically disables it to prevent runaway costs. The task shows an Auto-disabled reason in the table. To resume it, edit the task and re-enable it (which also resets the failure counter).

To see the execution history for a task, open the actions menu and click View Runs. Alternatively, click the Last Run status chip in the task table.

The run history modal shows each recorded execution with:

• Status (Completed, Failed, Running, or Cancelled)
• Started At timestamp in your local timezone
• A View Logs button for each run
• A Cancel button for runs that are currently Running — click Cancel to stop the agent mid-execution. A confirmation dialog appears before the run is cancelled.

OSC stores up to 50 run history entries per task. Older entries are pruned automatically when the limit is reached.

Clicking View Logs opens the log viewer for that run. Logs are paginated and can be downloaded as a plain text file. If a run's logs have expired (typically 2-7 days after completion), the log viewer shows an expiry notice instead.

Live mode: When you open the log viewer for a run that is currently in progress, live mode is enabled automatically — the viewer fetches new log entries every 3 seconds and scrolls to the bottom as they arrive. A red pulsing LIVE indicator shows when live mode is active. Click Stop live to pause and browse earlier entries at your own pace. For completed or failed runs, live mode is off by default; click Live to re-enable it if logs are still streaming.

Authentication failure callout: If a run failed because the OSC Access Token could not authenticate (e.g. it expired or was rotated without updating the task), the log viewer shows a warning banner above the raw logs:

OSC Access Token expired or invalid. This run failed because the OSC Access Token could not be authenticated. Rotate the token to fix future runs. [Manage tokens]

Click Manage tokens to go directly to your API settings page and rotate the token.

The Import button on the My Apps page lets you bring an existing GitHub repository into OSC as a managed My App. The import runs an AI agent that inspects the repository, creates a managed Gitea repository in your OSC workspace, pushes the code there, and then deploys the app.

1. Go to My Apps.
2. Click Import in the top-right corner of the page.
   • If you have not yet configured agent credentials, clicking Import opens a setup modal so you can enter your Anthropic or OpenAI API key before proceeding. Once saved, the Import dialog opens automatically.
3. Enter the GitHub Repository URL (e.g. https://github.com/owner/repo).
4. Optionally provide a GitHub Token if the repository is private.
5. If you have credentials configured for both Claude and Codex, select the Runner to use.
6. Click Import. OSC creates an agent task and triggers it immediately.

After the import starts, a success banner with a "View progress" link appears. Click it to open the My Agent Tasks page where you can follow the run logs.

1. Inspects the repository to determine the runtime (Node.js, Python, Go, or WASM).
2. Creates a managed Gitea repository in your OSC workspace.
3. Pushes the source code to that Gitea repository.
4. Deploys the app from the Gitea URL (not from GitHub directly) using create-my-app.
5. Reports the public URL and Gitea repository link when complete.

After a successful import, all future code changes and Agentic SDLC activity flow through your OSC-managed Gitea repository, not the original GitHub source.

If you have an AI agent connected to OSC via MCP, you can manage agent tasks using natural language.

For Claude Runner:

Set up my agent credentials using my Anthropic API key sk-ant-...

For Codex Runner:

Set up my agent credentials using my OpenAI API key sk-... for the codex runner

The setup-agent MCP tool accepts an agentType parameter to target the correct runtime. When you specify an OpenAI key the tool sets agentType to birme-codex-runner automatically. When you specify an Anthropic key it uses birme-claude-runner.

Create a task that runs with the default Claude Runner:

Create a daily task called "sync-report" that runs every weekday at 9am.
The prompt should be: Review the GitHub issues in my repo and post a summary to Slack.
Use https://github.com/myorg/myrepo as the source URL.

Create a task that uses a saved git credential instead of a raw token:

Create a daily task called "pr-reviewer" that runs every weekday at 8am.
The prompt should be: Review open pull requests in the repo and add triage comments.
Use https://github.com/myorg/private-repo as the source URL.
Use my saved git credential "my-github-token".

The gitCredential parameter takes the friendly name from your saved credentials (see list-git-credentials). It is mutually exclusive with gitToken — use one or the other. Using a saved credential means the raw PAT never appears in MCP arguments or conversation history.

Create a task that runs with Codex Runner:

Create a weekly task called "code-review" that runs every Monday at 8am using the Codex runner.
The prompt should be: Review open pull requests in the repo and add triage comments.
Use https://github.com/myorg/myrepo as the source URL.
Set agentType to birme-codex-runner.

Create a manual (on-demand) task:

Create a manual task called "data-migration" that I can trigger myself.
The prompt should be: Run the database migration script in scripts/migrate.js.
Use https://github.com/myorg/myrepo as the source URL.
Set scheduleType to manual.

List my agent tasks and show me which ones ran today.

Run my "sync-report" task now.

Delete the agent task called "old-task".

Update the "sync-report" task to run every Monday at 9am instead of every weekday.

To inspect all settings of a specific task before editing it:

Get the full definition of task task-abc123.

The get-agent-task tool returns the complete task definition including prompt, schedule, model, allowed tools, and credential status. This is especially useful before calling update-agent-task so you can read, merge your changes, and write back safely.

To stop a task that is currently executing, call stop-agent-task-run with the task ID and run ID:

Cancel run run-abc456 of task task-123.

The tool only affects runs in the Running state. If the run has already completed, failed, or been cancelled, the tool returns a non-error ALREADY_TERMINAL status so you do not need to guard against race conditions. Use get-agent-task-runs first to confirm the run is still active.

You can also cancel a running task from the web console: open the run history modal for the task and click Cancel next to the active run.

You can trigger a manual or on-demand task run directly from a CI/CD pipeline using a plain HTTP POST, without going through the MCP layer:

curl -X POST \
  https://deploy.svc.prod.osaas.io/myagents/tasks/{taskId}/run \
  -H "Authorization: Bearer {personal-access-token}"

Replace {taskId} with the task ID from list-agent-tasks and {personal-access-token} with a valid OSC personal access token. For GitHub Actions, store the token as a repository secret and reference it with ${{ secrets.OSC_PAT }}.

Show me the recent runs for my "sync-report" task.

Get the logs from the latest run of my "daily-report" task.

Show me the logs for run run-abc123 of task task-xyz.

The get-agent-task-logs tool automatically fetches the most recent run if you omit the runId. Logs are truncated to the last 200 lines for very long outputs, with a note indicating how many lines were omitted. If logs have expired the tool returns a friendly message explaining this.

A common use for an agent task is having the agent actually load a web page and check that a change is live, rather than trusting that a deploy succeeded. Browserhand gives the agent a real browser session it can navigate and read, which makes it well suited to this from inside a task.

Every Browserhand instance sits behind the standard OSC ingress, and that ingress returns a bare HTTP 401 (nginx's default error page, with no WWW-Authenticate header) for any direct call, with or without an auth header. This includes Authorization: Bearer <PAT>, x-pat-jwt, x-jwt, and osc-access-token; none of these authenticate a plain HTTP client against a Browserhand instance directly.

The only mechanism that works is the MCP tool call-service-endpoint. It authenticates server-side on OSC's infrastructure, so the calling agent never needs a token of its own:

call-service-endpoint(serviceId="birme-browserhand", instanceName="myinstance", endpoint="/v1/sessions", method="POST", body="{}")
→ 201 Created

If a task's prompt tries curl or fetch directly against the instance URL, it will get a 401 with no explanation. Instruct the agent to call the Browserhand API via call-service-endpoint instead of calling the instance URL directly.

To get access to call-service-endpoint, the task's OSC Access Token field must be left on Managed (the default, described in the field table under Step 3 above). Managed mode connects the task to mcp.osaas.io and exposes 140+ platform tools prefixed mcp__OSC__, including call-service-endpoint.

Reaching Browserhand requires no credential at all in Managed mode, which is different from the Parameter Store integration described under Advanced Settings above; that mechanism exists for tasks that need an actual application secret injected as an environment variable.

Create the instance first, the same as for any other service (see Browserhand: Step 1). Always pass explicit, non-empty values for both MaxConcurrentSessions and SessionTimeoutMs; there is a known issue (birme/browserhand#1) where an empty string from the orchestrator bypasses the service's default, leaving the instance misconfigured if either field is omitted. For example, via MCP:

create-service-instance(serviceId="birme-browserhand", config={"name":"myinstance","MaxConcurrentSessions":"5","SessionTimeoutMs":"30000"})

Once the instance is running, the agent drives a session entirely through call-service-endpoint:

Reading /v1/sessions/{id}/content and checking the returned text field for the string you expect is the core of this verification pattern. Browserhand also exposes snapshot, click, type, and other action endpoints for more interactive checks (for example, filling in a form and confirming the result). Have the agent call get-service-endpoints for the full, current list rather than hardcoding every path.

A task with a prompt like the one below, run once in Managed mode, verifies that a wiki page is live and contains expected text:

Create a Browserhand session, navigate to https://docs.osaas.io/osaas.wiki/Home.html,
read the page content, and confirm the text "Eyevinn Open Source Cloud" is present.
Report whether the check passed, then close the session.

Note: Some static sites require the full file path rather than a clean URL. docs.osaas.io/osaas.wiki/Home.html loads correctly, while the bare path docs.osaas.io/osaas.wiki/Home returns a 403 (S3-style AccessDenied) on this particular site. This is specific to how that site is hosted as a static export, not a Browserhand limitation; if a navigate call 403s unexpectedly, try the target page's full file path.

For a one-off check like this, create the task with scheduleType set to manual and trigger it with run-agent-task whenever you need it.

Write prompts as clear task descriptions. The agent runs non-interactively, so treat the prompt as a complete, self-contained instruction.

Claude Runner prompts:

• "Review open GitHub issues labeled 'bug' in myorg/myrepo and add a comment with a suggested fix approach."
• "Check the health of my OSC services and send a Slack message to #ops if any are unhealthy."
• "Fetch yesterday's analytics data from my Plausible instance and append a row to the Google Sheet at ..."
• "Generate a daily standup summary from my Jira board and post it to #team-standup."

Codex Runner prompts (works best with an AGENTS.md in the repository):

• "Run the daily report task described in AGENTS.md."
• "Review the code in src/ for potential bugs and write a summary to review.md."
• "Run the test suite and report any failures with suggested fixes."

For tasks that interact with code, set Source URL to the relevant repository so the agent can read and modify files in context.

Each runtime uses a different conventions file to understand the project:

• Claude Runner reads CLAUDE.md at the repository root (or in parent directories).
• Codex Runner reads AGENTS.md at the repository root.

If you switch a repository between runtimes, add the corresponding context file so the agent has the project background it needs.

• My Agent Tasks dashboard
• Codex Runner service page
• Connect AI Agents with OSC
• User Guide: Credentials and Secrets — when to use Anthropic API key vs Claude OAuth token vs OpenAI API key