Same agent. Same task. Every week?
Put it on a schedule with SecondShift.
Give your coding agents recurring tasks: investigate CI failures, check release readiness, or close fixed issues through an approved service connection. Commit a skill, set a schedule, and follow what gets done.
Your team controls their access. Every run leaves an audit trail.
secondshift-product-demo-v2-60s-4k-inline.mp4
Commit a skill and its schedule alongside your code, connect a model, and approve the tools it may use. Skills can read data and take actions through approved MCP tools or HTTP API operations. Results can arrive in Slack or another webhook destination. Commands run in an isolated sandbox. Each run records its Git revision, tool activity, and model cost.
Install uv to manage the application and start Docker for job sandboxes, then run:
# Install SecondShift
release=https://github.com/piotrekno1/second-shift/releases
uv tool install --force --python 3.13 \
"$release/download/v0.1.0b2/secondshift-0.1.0b2-py3-none-any.whl"
# Start SecondShift
secondshift upUpgrading from an alpha? This beta resets database migrations and requires a fresh database. Read the beta release notes first.
Once started, the console shows:
SecondShift is running at http://127.0.0.1:8000
Sign in with this link. It works once, within 15 minutes:
http://127.0.0.1:8000/-/sign-in/<one-time-token>/
Run `secondshift login` for a new link. Press Ctrl+C to stop.
SecondShift is in beta, distributed through GitHub Releases until it is available on PyPI.
For a shared installation on a Linux server, follow the Docker Compose deployment guide. The example sets up Caddy with automatic HTTPS, PostgreSQL, and a gVisor runner, and connects to your private S3-compatible bucket. The guide covers GitHub App configuration, initial setup, backups, and updates.
- See what is on duty. The control room shows upcoming shifts, recent runs, failures, and model spend.
- Manage schedules from Git. Discover jobs from
.secondshift.yaml, review their skills and schedules, and enable or run them manually. - Connect models and report destinations. Add a model provider and webhook, then approve each job's notification access. Connections remain separately revocable.
- Connect skills to your services. Connect GitHub, Sentry, any MCP server (OAuth or a token), or an HTTP API from its OpenAPI spec. Choose which tools jobs may use, then approve each job's request, including operations that change data. Calls run outside the sandbox. Built-in GitHub and Sentry tools are read-only.
- Follow every run. Inspect its Git revision, execution timeline, report, token usage, and model cost.
Write a skill for recurring work your team needs done. Connect the services it needs through MCP or an HTTP API, then approve the job's access.
Task examples include:
- Documentation drift finds broken links and stale commands in your docs. It needs only a model provider.
- CI failure review groups recurring build failures and identifies what still blocks work.
- Ticket reconciliation updates or closes tickets when linked changes meet your team's completion rules.
Browse the full skill catalog to choose a workflow and see what data it needs. Follow the engineering task setup guide to copy a skill, approve access, try it manually, and enable scheduling.
For teams that want a person to decide, the ticket follow-up brief lists candidates without changing tickets. See tasks that change service data for access requirements and workflow setup.
| Role | Controls |
|---|---|
| Repository contributors | Propose skills, schedules, and requested capabilities through Git changes. |
| Repository maintainers | Review and merge those changes through the repository's normal process. |
| Workspace owners | Connect model providers and services, approve each job's access, add local repositories, and invite people and manage their roles. |
| Workspace admins | Enable, run and schedule approved jobs, manage repositories, and change run limits. |
| Workspace members | View repositories, jobs and runs. |
| Server operators | Define sandbox images, runtimes, resource limits, and network policy. |
Each workspace role can also do everything the roles below it can. The full
list of actions and the role each needs is POLICY in
secondshift/workspaces/access.py.
A committed skill does not grant itself access. Repository configuration cannot choose credentials, provider endpoints, sandbox images, mounts, or network settings. Expanding requested capabilities requires renewed approval.
Skills run in isolated sandboxes. Every run is tied to a Git commit.
Hermes Agent is individual-first, centered on an agent that remembers your context and works across your tools. SecondShift is team-first, built around recurring engineering tasks managed through Git, explicit permissions, and shared run history. Both can serve individuals or teams.
Hermes already supports scheduled skills and report delivery. In SecondShift, review the skill and schedule in Git, approve its service access separately, and inspect each run's revision, tool activity, report, and cost. Workspace roles separate who can grant access, operate jobs, and view results.
A merged skill cannot grant itself credentials or expand its approved access. Commands run in a networkless sandbox. External tool calls go through a broker that checks the job's approved permissions. See the security model for the boundaries and remaining risks.
An existing scheduler can start an agent on a timer. SecondShift also handles job discovery from Git, access approvals, sandbox execution, run history, model cost tracking, and report delivery. It gives teams one place to manage that work across repositories.
SecondShift is early, and contributions are welcome: bug reports, ideas, documentation improvements, and pull requests. See CONTRIBUTING.md to get started. For larger changes, open an issue first so we can discuss the approach.
- Repository configuration: skills, YAML syntax, schedules, and notifications.
- Engineering tasks: skill setup, approved service actions, and scheduling.
- Environment variables: service-scoped configuration and setup file generation.
- Architecture: execution design and capability boundaries.
- Security model: what a run can reach, where secrets live, and remaining risks.
- Self-hosting (work in progress): runner backends, sandbox images, and artifact storage.
- Contributing: source setup, development, verification, and releases.