chore(jetbrains): disable feedback surveys and enable internal mode in dev runs

[kirillk]

Issue

Fixes #

No tracked issue. This was raised ad hoc: IntelliJ's built-in remote-dev "Share Your Experience" / "Take Survey" feedback popup was interrupting local plugin dev sessions (runIdeSplitMode / runIdeBackend / runIdeFrontend).

Context

IntelliJ Platform's platform/feedback framework periodically shows feedback surveys (CSAT, Editor UX, remote-dev satisfaction, etc.) inside the sandbox IDE. These are gated by registry keys that default to enabled and persist "Don't Suggest Again" state in the sandbox config, so they resurface whenever the sandbox is reset. This PR disables the whole survey framework unconditionally for local dev runs so it never interrupts plugin development.

While in there, also turned on IntelliJ Internal Mode (idea.is.internal=true) unconditionally for the same dev-run tasks, since the docs previously told developers to pass -Didea.is.internal=true manually to use the Split Mode latency-emulation widget.

Implementation

Both changes live in the existing tasks.withType<RunIdeTask> block in packages/kilo-jetbrains/build.gradle.kts, which already applies to runIde, runIdeBackend, runIdeFrontend, and runIdeSplitMode — no new task wiring needed.

• platform.feedback=false — master switch for the platform/feedback extension point framework (disables every registered feedback.idleFeedbackSurvey, including the remote-dev one).
• csat.survey.enabled=false and editor.ux.survey.enabled=false — per-survey keys that exist independently of the master switch.
• idea.is.internal=true — maps to ApplicationManagerEx.IS_INTERNAL_PROPERTY.

All four are IntelliJ Platform Registry keys. RegistryValue.resolveRequiredValue falls back to System.getProperty(key) when no stored value exists, so Gradle's systemProperty(...) on the forked JVM is sufficient — no plugin-side code changes.

Property names were verified against a local intellij-community checkout rather than guessed:

• platform.feedback, csat.survey.enabled, editor.ux.survey.enabled — declared in platform/feedback/resources/intellij.platform.feedback.xml.
• idea.is.internal — ApplicationManagerEx.IS_INTERNAL_PROPERTY in platform/core-impl/.../ApplicationManagerEx.java; also how JetBrains' own IDEA run configs and the DevKit plugin set it.

Caveat documented in AGENTS.md: in split mode, the JetBrains Client frontend process is spawned by the backend, and EmbeddedClientLauncher.passProperties only forwards a fixed allowlist of properties to it. idea.is.internal is on that allowlist, but the feedback/survey keys are not — so a survey could in theory still surface in the split-mode client window specifically, requiring a Registry override inside that client.

Screenshots / Video

N/A — no UI change; this only affects local Gradle dev-run JVM args.

How to Test

Manual/local verification

• ./gradlew --no-configuration-cache runIdeSplitMode --dry-run and runIdeBackend --dry-run — task graph realizes successfully with the new systemProperty calls in the RunIdeTask configuration block (agent-executed).
• bun turbo typecheck --filter=@kilocode/kilo-jetbrains (via the repo's pre-push hook) — ./gradlew typecheck passes, confirming the Gradle script change doesn't break configuration or compilation (agent-executed).
• bun run script/check-md-table-padding.ts — passes on the AGENTS.md edit (agent-executed).

Reviewer test steps

1. From packages/kilo-jetbrains/, run ./gradlew --no-configuration-cache runIdeSplitMode (or runIdeBackend).
2. Confirm the sandbox IDE starts without showing any "Share Your Experience" / feedback survey popup during the session.
3. Open Help → Find Action → Registry… and confirm idea.is.internal reads true, or trigger the Split Mode latency widget (only available in internal mode) and confirm it's present.

Blocked checks and substitute verification

• Did not run a full interactive runIdeSplitMode session end-to-end (requires downloading/booting a full sandboxed IDE and manually watching for the popup over time); substituted with the --dry-run task-graph check plus source-level confirmation that systemProperty on RunIdeTask reaches the forked JVM and that the Registry API reads System.getProperty as a fallback.

Checklist

• Issue linked above, or exception explained
• Tests/verification described
• Screenshots/video included for visual changes, or marked N/A
• Changeset considered for user-facing changes — not needed, dev-run tooling only, nothing ships in the plugin
• I personally reviewed the diff and can explain the changes, including any AI-assisted work.

Get in Touch