Can copilot-setup-steps job timeout-minutes maximum value: 59 be increased further or this cap be removed

[vgithib]

Select Topic Area

Question

Copilot Feature Area

Copilot in GitHub / Copilot Coding Agent

Body

In self hosted copilot jobs, the "Processing Request" step of the job get's killed after 59 mins. Can this copilot-setup-steps job timeout-minutes maximum value: 59 mins setting be increased further to a sufficiently high value (say 6 hrs) or can this cap be removed altogether.
Reference Doc

In your copilot-setup-steps.yml file, you can only customize the following settings of the copilot-setup-steps job. If you try to customize other settings, your changes will be ignored.
timeout-minutes (maximum value: 59)

[GauravAthode]

Currently, the 59-minute limit for the copilot-setup-steps job is a fixed cap and cannot be increased or removed. This limit is enforced by GitHub and any higher value is ignored.
If setup regularly takes longer, the recommended approach is to optimize the setup steps or move long-running work to later jobs in the workflow instead of the Copilot setup phase.

[theophanemayaud]

Is this 59 minute limit a max for how long the setup can take, or how long copilot can run for ?

[GauravAthode]

The 59-minute limit applies only to the copilot-setup-steps job. It's a hard timeout for the setup phase and does not limit how long Copilot can work overall. Once the setup completes, the remaining workflow jobs run under the normal GitHub Actions job timeout limits for your runner and plan.

[Sandeshkadel]

## 1. Overview

When using GitHub Copilot coding agents inside workflows on GitHub, you may encounter a configuration where the copilot-setup-steps job has a maximum allowed value:

timeout-minutes: 59

Developers sometimes want to increase this timeout for long-running environment setup tasks. The key question is whether this limit can be increased or removed.

---

# 2. Short Answer

No.
The copilot-setup-steps job currently has a hard platform limit of 59 minutes, and it cannot be increased or removed.

This restriction is enforced by the Copilot execution environment and is not configurable by users.

---

# 3. Why the Limit Exists

The limitation comes from how the Copilot runtime environment works inside the GitHub infrastructure.

Copilot agents run in temporary sandbox environments built on top of the GitHub Actions execution model.

These environments are designed to be:

• ephemeral
• resource isolated
• automatically cleaned up
• predictable in execution time

To guarantee stability and resource fairness across users, GitHub enforces strict runtime caps.

The copilot-setup-steps phase is specifically intended only for environment preparation, not long-running tasks.

---

# 4. Difference Between Copilot Setup Jobs and Normal Actions Jobs

Normal GitHub Actions jobs can run much longer depending on the runner type.

Typical limits are:

GitHub-hosted runner

• maximum job runtime: 6 hours

Self-hosted runner

• runtime limit: controlled by the runner operator

However, copilot-setup-steps runs in a restricted Copilot agent environment, which is separate from the normal Actions job execution.

Therefore it has a stricter cap.

---

# 5. What the copilot-setup-steps Phase Is Intended For

This phase is designed only for lightweight preparation tasks, such as:

• installing required CLI tools
• fetching dependencies
• configuring environment variables
• preparing project workspace

Examples of appropriate setup tasks:

npm install
pip install -r requirements.txt
apt-get install jq

It is not intended for:

• large builds
• compilation of heavy dependencies
• long-running scripts
• extensive downloads

---

# 6. Recommended Workarounds

Although the timeout cannot be increased, there are several effective strategies to handle longer setup requirements.

---

## Solution 1: Move Heavy Work to a Separate Job

Instead of performing heavy tasks during copilot-setup-steps, move them into a normal workflow job.

Example:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install
      - run: npm run build

Then allow Copilot to operate after the build artifacts are ready.

---

## Solution 2: Cache Dependencies

Use caching to significantly reduce setup time.

Example:

- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: npm-${{ hashFiles('package-lock.json') }}

Caching avoids repeated downloads and installations.

---

## Solution 3: Prebuild a Development Container

If your environment requires many dependencies, create a prebuilt container image.

Example Dockerfile:

FROM node:20

RUN npm install -g pnpm
RUN apt-get update && apt-get install -y jq

Then use that image during setup so the environment starts almost instantly.

---

## Solution 4: Reduce Setup Complexity

Many setup steps can be optimized:

• use lockfiles
• minimize package downloads
• remove unnecessary tools
• precompile dependencies

Reducing setup complexity helps ensure the process finishes well within the 59-minute window.

---

# 7. Best Practice Architecture

A recommended workflow structure for Copilot projects is:

Environment Preparation
        ↓
Dependency Cache Restore
        ↓
Light Setup (<10 minutes)
        ↓
Copilot Agent Execution
        ↓
Normal CI Jobs (build/test)

This keeps the Copilot environment responsive and avoids hitting timeout limits.

---

# 8. Conclusion

The copilot-setup-steps job timeout limit of 59 minutes is currently fixed and cannot be increased or removed.

This cap exists because Copilot runs inside a managed sandbox environment optimized for quick setup and short-lived execution.

If your setup exceeds this limit, the recommended approach is to:

• move heavy tasks into normal workflow jobs
• cache dependencies
• use prebuilt environments
• simplify setup procedures

Following these practices ensures reliable Copilot execution while staying within the platform’s constraints.

[theophanemayaud]

So, is it the setup tasks that can be max 59 minutes, is is the agent part also max 59 minutes ?

[CezaryKlus]

I encountered the same hard limit on the actual agent execution job. I have invested in creating quite sophisticated agent orchestration that, overall, is a long process and now facing a timeout when I want to execute it as a cloud agent.

[cartergray234]

The 59-minute limit is currently enforced and can't be increased. If your setup needs longer, you'll need to optimize or split the initialization into smaller steps. This would be a valuable enhancement request.