Skip to content

docs: add Cursor Cloud specific instructions - #882

Draft
rrama wants to merge 3 commits into
masterfrom
cursor/cloud-env-setup-notes-ca2c
Draft

docs: add Cursor Cloud specific instructions#882
rrama wants to merge 3 commits into
masterfrom
cursor/cloud-env-setup-notes-ca2c

Conversation

@rrama

@rrama rrama commented Jul 29, 2026

Copy link
Copy Markdown
Contributor

Description

Adds a ## Cursor Cloud specific instructions section to AGENT.md, recording what an
agent needs to know to build and test this plugin in a Cursor Cloud Linux VM.
Documentation only — no plugin code changes.

This is the only cloud-setup PR against this repo, so there was no duplicate to close.
Instead this revision corrects the stale claims in the original notes.

The notes cover:

  • The default branch is master, not main.
  • JDK 21 plus the Gradle wrapper (Gradle 8.14.1; there is no system gradle).
  • ./gradlew buildPlugin and ./gradlew test both pass — roughly 626 tests in about
    5 minutes, green, with no extra flags.
  • Which hosts dependency resolution actually needs, and why failures look like
    flakiness rather than a permissions problem.
  • runIde needs a display; verifyPlugin does not, but is expensive (see below).

What changed since the first revision

  • Corrected the headline claim: this repo is no longer blocked. The original notes
    described plugin resolution failing at the TLS layer as the current state. It builds and
    tests cleanly once oss.sonatype.org and plugins-artifacts.gradle.org are reachable,
    so the section now says so explicitly and warns against using the old "unbuildable" note
    as a reason to skip the repo.
  • Added three findings that shrink the allowlist surface rather than asking for more
    entries:
    • cache-redirector.jetbrains.com proxies both the Gradle Plugin Portal m2 and Maven
      Central, so routing through it avoids plugins-artifacts.gradle.org entirely.
    • The oss.sonatype.org entry in settings.gradle.kts is effectively vestigial — all
      seven plugins (changelog, intellij.platform, kotlin.jvm, kover, spotless,
      ktlint, axion-release) are pinned to Plugin Portal releases, and the only
      SNAPSHOT in the build is the project's own axion-release version.
    • repo1.maven.org is commonly blocked and is not required; Central resolves via
      repo.maven.apache.org.
  • Corrected both halves of the runIde / verifyPlugin claim. The first revision
    lumped them together as needing a display and therefore out of scope.
    • verifyPlugin runs headless; its real cost is that pluginVerification in
      build.gradle.kts targets four full IDE distributions (IC 2025.2 plus IU 2025.3,
      2026.1 and 2026.2), so a cold run pulls roughly a gigabyte. Verified here: a cold
      ./gradlew verifyPlugin test took 9m57s and downloaded 946 MB.
    • runIde is usable — cloud VMs here have run XFCE on DISPLAY=:1, and driving
      the sandbox IDE is the strongest available proof, since building and unit-testing do
      not show the plugin works inside a running IDE. The section now covers the sandbox
      launch and the Settings › Tools › Snyk configuration.
  • Flagged that verifyPlugin and test are pre-push hooks. A cold run outlasts
    GitHub's SSH idle timeout and the push dies with Connection to github.com closed by remote host, which reads like a network fault rather than a slow hook. Running both
    before pushing avoids it.
  • Recorded the authentication gotchas: the token is read from the plugin's own
    settings, so neither SNYK_TOKEN nor the CLI's ~/.config/configstore authenticates
    it — snyk auth in a terminal does nothing — the API-token method is required because
    the OAuth2 browser flow times out, and the plugin's folder-trust gate is separate from
    the IDE's workspace trust.
  • Removed the hard-coded reachable/blocked host list. The egress allowlist changes
    between runs, so a fixed map goes stale and gets trusted anyway. Readers are told to
    probe directly, with the semantics that actually bite: bare entries are apex-exact while
    *.example.com covers subdomains only.

Checklist

  • Read and understood the Code of Conduct and Contributing Guidelines.
  • Tests added and all succeed — n/a, no code changes; markdown only. The full suite
    was run in the cloud VM to verify the claim in the notes (~626 tests, green).
  • Linted — n/a, no Kotlin touched; the spotless/ktlint pre-commit hook passed
  • README.md updated, if user-facing — n/a, contributor/agent documentation

Screenshots / GIFs

n/a — documentation only.

Co-authored-by: Ben Durrans <Benjamin.Durrans@snyk.io>
@snyk-io

snyk-io Bot commented Jul 29, 2026

Copy link
Copy Markdown

Snyk checks have passed. No issues have been found so far.

Status Scan Engine Critical High Medium Low Total (0)
Code Security 0 0 0 0 0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

@github-actions

github-actions Bot commented Jul 29, 2026

Copy link
Copy Markdown
Contributor

Code Coverage

Total Project Coverage 48.32%

rrama and others added 2 commits July 30, 2026 13:36
Corrects the main stale claim: this repo is no longer blocked in the cloud VM.
buildPlugin and the full test suite (~626 tests, JDK 21) both pass once plugin
resolution can reach its hosts, so the earlier 'unbuildable' note should not be
used as a reason to skip it.

Adds three findings that reduce the allowlist surface: cache-redirector
.jetbrains.com proxies both the Gradle Plugin Portal m2 and Maven Central, the
oss.sonatype.org entry is vestigial because all seven plugins are pinned to
Plugin Portal releases, and repo1.maven.org is not required.

Documents that runIde is usable where the VM provides a display, since building
and unit-testing do not prove the plugin works inside a running IDE, and records
the authentication gotchas: the token comes from the plugin's own settings rather
than SNYK_TOKEN or the CLI configstore, OAuth2 times out so the API-token method
is required, and the plugin applies its own folder-trust gate.

Notes that verifyPlugin and test are pre-push hooks whose cold run can outlast
the SSH connection, and replaces the fixed reachable/blocked host list with
guidance to probe egress directly.

Co-authored-by: Cursor <cursoragent@cursor.com>
A warm VM can report `test` as UP-TO-DATE and succeed in seconds having
executed nothing, which a setup run read as a green suite. Also correct the
egress note: the allowlist changes only when someone asks the admins, so the
reason not to trust a written host list is document drift, not churn.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants