Case-duplicate Cloud Environments keep recreating for Secureiv/fs (canonical vs lowercase)

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cloud Agent (GitHub, Slack, Web, Linear)

Describe the Bug

Our Cursor team has two Cloud Agent Environments for the same private GitHub repository, differing only by owner casing.

  1. Canonical (correct / in use)
  • Display: Secureiv/fs
  • Environment ID: c20a7937-8f35-11f1-a7d1-d6b4613131ce
  • How to open: Cursor Dashboard → Cloud Agents → Environments → that ID
  • Cloud MCP: source=Repository, recordedVia=REPO_FILE_OBSERVED, repos host=GitHub path=Secureiv/fs
  • Builds: enabled. MANUAL builds succeed; SYSTEM+RECURRING builds fail instantly (~0.1s) with TERMINAL_FAILURE, empty logs, environmentVersionId=null
  • Live Cloud Agents bind to this environment
  1. Duplicate (keeps recreating with NEW UUIDs)
  • Display: secureiv/fs
  • Previous ID: 09fd2e99-92cf-11f1-ba66-0e7d0216e441
  • Latest recreated ID: 5ab45d88-960f-11f1-ba66-0e7d0216e441
  • Builds: typically NOT enabled (Enable Builds for Faster Cloud Agents)
  • After cleanup, a new lowercase environment appears again with a different UUID
    Both environments show the banner:
    “This environment is managed by a .cursor/environment.json file in the repository. Edit it in code and commit to update.”
    Important: our repo file does NOT contain any repo URL or casing.
    .cursor/environment.json only has:
  • name: “fs-kyle-ui-verify”
  • install / start / ports
    No “Secureiv” or “secureiv” string exists in the file (confirmed via git history from initial add).
    GitHub canonical casing (API login/full_name) is Secureiv / Secureiv/fs.
    GitHub treats owner/repo as case-insensitive, but Cursor appears to key Environments by exact repo URL string, creating duplicates.
    Related (not the same bug; for staff cross-ref by topic id only):
  • ManagePullRequest fails when repo owner casing differs from GitHub canonical (staff confirmed case-sensitive repoUrl). Topic id: 166397
  • Duplicate environment entries for the same repo from Personal vs environment.json switching (not casing). Topic id: 161554

Steps to Reproduce

  1. Have a GitHub org/repo with mixed-case canonical login (Secureiv/fs) and committed .cursor/environment.json
  2. Open Dashboard → Cloud Agents → Environments; observe Secureiv/fs and secureiv/fs both listed
  3. Delete or ignore the lowercase one
  4. Later, a new lowercase environment reappears with a new UUID (example: 5ab45d88-960f-11f1-ba66-0e7d0216e441)

Expected Behavior

One Environment per GitHub repository (case-insensitive), keyed by GitHub repo id / canonical full_name.
Deleting the lowercase duplicate should not recreate it.
Scheduled RECURRING builds should either succeed or fail with inspectable logs (not instant TERMINAL_FAILURE with 0-byte logs).

Actual Behavior

  • Case-duplicate Environments keep recreating with new UUIDs
  • Both show managed-by-environment.json banner (banner is not a reliable canonical indicator)
  • RECURRING builds on the canonical env fail instantly with no logs; MANUAL builds succeed

Operating System

Other

Version Information

N/A for Cursor Desktop — issue is on the Cloud Agents Dashboard Environments UI.
Investigation Cloud Agent (web-launched):

  • bcId: bc-cdb24b89-b293-4a31-b5be-76d9a13e7b3d
  • source: web
  • model: auto-smart
  • Canonical env: c20a7937-8f35-11f1-a7d1-d6b4613131ce
  • Duplicate env (latest): 5ab45d88-960f-11f1-ba66-0e7d0216e441
  • Example successful MANUAL build: bld-20260808-e0e3c9b2-af12-4773-a1be-69a9ff08eef9

Additional Information

  • Repo: GitHub org Secureiv / name fs (private)
  • We are NOT asking whether lowercase should be preferred; GitHub canonical is Secureiv and agents already run on c20a7937-…
  • Workaround: use only the Secureiv/fs environment; ignore lowercase; do not Enable Builds / attach Secrets on the duplicate

Does this stop you from using Cursor

No - Cursor works, but with this issue

7

Hey @Mikio,

Lowercase env keeps coming back: it recreates whenever an agent launches with the lowercase URL, usually from a git remote saved in lowercase. On the machines launching agents, run git remote -v and reset any lowercase origin to canonical casing: git remote set-url origin https://github.com/Secureiv/fs.git (also check any scripts/automations that start agents). Then delete the lowercase env once and it should stay gone. Making environment matching case-insensitive is on our side and something we’re tracking.

Scheduled builds failing instantly: the GitHub App installation for your org isn’t currently tied to your team, so scheduled builds fail while manual ones (which use your own credentials) succeed. A team admin who’s also a GitHub org admin can fix it at Integrations → next to GitHub, Manage Connections (Disconnect first if needed) → reconnect while signed in to your team, and confirm the app has access to Secureiv/fs.

Let me know how both go!

8

Thanks @mohitjain — update on both:

  1. Lowercase env
  • We shared your git remote / launch-URL guidance with our team.
  • That side looks addressed on our end; thank you.
  • Case-insensitive matching on your side would still help a lot.
  1. Scheduled builds
  • Reconnecting GitHub under Integrations → Manage Connections was not enough; SYSTEM/RECURRING builds still failed instantly afterward.
  • We’ve now reconnected and also recreated the Secureiv/fs environment (canonical casing only).
  • That looks resolved, but we’ll follow up if anything comes up again.

Thanks again!

9

Quick update on the scheduled builds: we still haven’t resolved the issue. I’ve completely deleted the environment and set it up again from scratch, but we’re still running into repeated errors. Right now, we’re having to manually trigger the builds and repeat the update process by hand.