System clock is incorrect when cloud agent install script runs

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cloud Agent (GitHub, Slack, Web, Linear)

Describe the Bug

I have a project with a simple .cursor/environment.json:

{
  "install": ".cursor/cloud/install.sh"
}

The install.sh prints the date and runs some apt-get commands:

#!/bin/bash

set -euo pipefail

echo "$0: $(date)"

# Ubuntu 24.04 ships only OpenJDK 21. Installing the .deb runs update-alternatives, so java on PATH
# becomes 25 and the build needs no JAVA_HOME.
curl -fsSL https://packages.microsoft.com/keys/microsoft.asc \
    | sudo gpg --dearmor --yes -o /usr/share/keyrings/microsoft-prod.gpg
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/microsoft-prod.gpg] https://packages.microsoft.com/ubuntu/24.04/prod noble main" \
    | sudo tee /etc/apt/sources.list.d/microsoft-prod.list >/dev/null
sudo apt-get update -qq
sudo DEBIAN_FRONTEND=noninteractive apt-get install -y -qq msopenjdk-25

It’s failing because the system clock is 3 days ago (July 24), so the InRelease file timestamps appear to be in the future from its perspective.

>>> [install:] start
.cursor/cloud/install.sh: Fri Jul 24 08:44:35 PM UTC 2026
E: Release file for https://packages.microsoft.com/ubuntu/24.04/prod/dists/noble/InRelease is not valid yet (invalid for another 20h 30min 3s). Updates for this repository will not be applied.
E: Release file for https://dl.google.com/linux/chrome/deb/dists/stable/InRelease is not valid yet (invalid for another 2d 2h 9min 42s). Updates for this repository will not be applied.
E: Release file for https://dl.google.com/linux/chrome-stable/deb/dists/stable/InRelease is not valid yet (invalid for another 2d 2h 9min 42s). Updates for this repository will not be applied.
E: Release file for http://archive.ubuntu.com/ubuntu/dists/noble-updates/InRelease is not valid yet (invalid for another 2d 0h 0min 22s). Updates for this repository will not be applied.
E: Release file for http://security.ubuntu.com/ubuntu/dists/noble-security/InRelease is not valid yet (invalid for another 1d 23h 59min 51s). Updates for this repository will not be applied.
E: Release file for http://archive.ubuntu.com/ubuntu/dists/nob [truncated]

Steps to Reproduce

Create a cloud agent with a .cursor/environment.json that runs an install script that prints the date.

Expected Behavior

System clock should be close to correct before running the install script, otherwise TLS and other verifications will tend to fail.

Operating System

MacOS

Version Information

Cloud agent

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Hey there! This is a real issue on our side, not your config.

Cloud agent VMs can start with the system clock set in the past (you caught ~3 days), so apt sees the repository InRelease files as “not valid yet” and refuses them. The same skew can also break TLS certificate validation and token expiry inside your install script. We’ve reproduced it and are actively working on a fix.

Until that lands, the most reliable workaround is to correct the clock at the very top of your install script, before any apt or HTTPS calls:

#!/bin/bash
set -euo pipefail
# Cloud agent VMs can boot with a stale clock; sync it before apt/TLS run.
sudo date -u -s "$(curl -fsSI -k https://cursor.com | tr -d '\r' | sed -n 's/^[Dd]ate: //p')"
echo "$0: $(date)"
# ...rest of your script (microsoft.asc, apt-get update, msopenjdk-25, etc.)

The -k on that single curl skips cert checking for the time lookup only (the clock is still wrong at that point, and it just reads the Date: response header, so nothing is sent). Once the clock is correct, the rest of your script runs normally.

If you’d rather keep it apt-only, you can tell apt to skip the date check, though this won’t help the TLS/signing steps elsewhere in your script:

echo 'Acquire::Check-Valid-Until "false";
Acquire::Check-Date "false";' | sudo tee /etc/apt/apt.conf.d/99no-check-valid >/dev/null

I’d go with the clock sync since your script also does TLS and package signing. I’ll follow up here once the underlying fix ships.