Leetcode Editor: Solving LeetCode Problems Inside Your JetBrains IDE

What Leetcode Editor solves, and who it is for

The browser tab is the friction. LeetCode's web editor is fine for short problems, but if you already have a JetBrains IDE open, switching to a browser means losing your keymaps, your debugger, and your local test setup. Leetcode Editor moves the problem list, the statement, the code template and the submission action into the IDE. The README describes it as a way to solve LeetCode problems without leaving your IDE, and lists browsing, local debugging and submissions as the core loop.

The target user is a developer who practices algorithms in a JetBrains IDE. The plugin supports IntelliJ IDEA, PhpStorm, WebStorm, PyCharm, RubyMine, AppCode, CLion, GoLand, DataGrip, Rider, MPS and Android Studio. That list is broad because the plugin is built on the JetBrains platform rather than one language. If you use PyCharm for Python practice or GoLand for Go practice, the same plugin applies. If you use VS Code or a terminal, this project does not help you.

How the plugin works: problem navigator, temp files and submissions

Leetcode Editor is a JetBrains plugin written in Java. The repository layout shows a standard Gradle plugin project: build.gradle.kts, gradle.properties, settings.gradle.kts, and source under src/. The README points to shuzijun/lc-sdk as the open functionality layer underneath, which suggests the plugin talks to LeetCode through a separate SDK rather than embedding all API calls in the IDE code.

The visible surface is a tool window called the Problem Navigator. Its toolbar has actions for sign in, sign out, refresh, pick a random problem, find/filter/sort, session switching, toggling between All Problem List, Paginated Problem List and CodeTop Problem List, settings, and clear. The context menu on a problem offers open question, open content, open solution, open in web, submit, submissions, run code, testcase, favorite, note, timer, and clear cache. The editor right-click menu exposes the same actions.

The data flow implied by the README is: the plugin fetches problem metadata and statements from leetcode.com or leetcode.cn, writes a temporary file into the configured Temp File Path using a code template, and sends the file contents back when you submit. The generated file is what you edit. The README warns that the Clear action removes files from the cache directory for the current website, and says to use it carefully when work has not been submitted. That is a direct statement that the cache is not a backup.

Installing Leetcode Editor and running a first problem

The README gives three installation routes: the JetBrains Marketplace, a package from GitHub Releases, or the paid LeetCode Editor Pro. The Marketplace route is the normal one for day-to-day use. There is no command-line install step documented in the README, so the tutorial below follows the settings path the README describes.

After installing and restarting the IDE, open the settings page. The README gives the path as File, then Settings, then Tools, then LeetCode Plugin.

In that page, set URL options to leetcode.com or leetcode.cn, choose a Code Type (the README lists Java, Python, C++, Python 3, C, C#, JavaScript, Ruby, Swift, Go, Scala, Kotlin, Rust, PHP, Bash and SQL), and enter LoginName and Password for the selected site. Set Temp File Path to a directory you are happy to have generated files written into. If you are behind a proxy, the README points to the HTTP Proxy page under Appearance & Behavior and System Settings.

Back in the Problem Navigator, click the refresh icon. The README notes that refresh loads problems without signing in, but submitting still requires an account. Double-click a problem to open it, or right-click and choose Open question. A file is generated in your Temp File Path. Edit the solution, then right-click and choose Run Code to run the default test case, or Testcase to create custom cases. When you are ready, choose Submit. The README says submission records are available under Submissions, with a Show detail option in the pop-up window. If sign-in fails, the README's own advice is to sign out first and try again.

Where Leetcode Editor stops being the right tool

The README is explicit that accounts for leetcode.com and leetcode.cn are independent. If you practice on both sites, you configure and sign in twice, and there is no documented account-linking or profile-merge behavior. That matters for anyone who wants one history across regions.

The plugin is also a client for the two public LeetCode sites, not a general judge. It does not claim to support company-specific question sets, private contests, or the paid LeetCode subscription features beyond what the web API exposes. The README does not document offline mode, so if the network or the LeetCode API is unreachable, the problem list and submissions are affected; the README's only fallback is the refresh action, which it says works without signing in. There is no documented rollback for a submission, and no documented way to recover a file after using Clear on the cache directory. Treat the generated files as working copies, not as an archive. If you want your solutions versioned, move them into your own repository yourself; the README does not describe an export or sync feature.

Leetcode Editor versus a plain browser and a local editor

The obvious alternative is the LeetCode website plus whatever editor you already use. The difference is where the state lives. With the browser, the problem statement, the code, the test run and the submission all live in one page, and you lose that page when you close the tab. With Leetcode Editor, the problem statement is a tab in the IDE, the code is a file on disk under Temp File Path, and the submission is a context-menu action. You gain your own debugger, your own linter and your own keybindings. You lose the web editor's instant feedback loop and any web-only feature the README does not mention.

A second alternative is copying problems into a local project and submitting manually through the browser. That keeps full control of the files and needs no plugin, but you maintain the problem statements and test cases yourself. Leetcode Editor automates the fetch and the submit step; the trade-off is that it owns the file layout and the cache, which is why the README's Clear warning exists.

Maintenance, releases and what the Apache-2.0 licence means here

The repository is not archived, and the last push was on 2026-08-13, which is recent. The release list shows v2026.2.0-pub (labelled v2026.2.0-Pro) and v9.0.0 on 2026-08-13, with v2024.1.7-pub before that on 2025-10-30. The presence of a Pro plugin on the JetBrains Marketplace alongside the open plugin means the project has a commercial side; the README links to LeetCode Editor Pro and to a donation page, and does not describe what is exclusive to Pro. That is a gap worth checking on the Marketplace listing before you plan around the open plugin.

The licence is Apache-2.0. That permits use, modification and redistribution under the terms in the LICENSE file, and it includes a patent grant. It does not give you the LeetCode name, the problem content, or the Pro plugin. The README does not state a support policy or a compatibility matrix beyond the IDE list, so upgrading the plugin after an IDE upgrade is something you verify yourself. The CHANGELOG.md at the repository root is the place to check what changed between releases.

Configuration details that trip people up

LevelColour is a settings key that customizes problem-difficulty colors, and the README says to restart the IDE after changing it. That is an unusual requirement for a color setting and worth knowing before you spend time wondering why nothing changed. Custom code template is another settings area; the README links to a separate custom-code document and an example repository (shuzijun/leetcode-question) rather than describing the template syntax inline. If you need a non-default file header, package declaration, or class name, expect to read those documents.

The proxy setting lives outside the plugin's own settings page, under Appearance & Behavior, which is easy to miss when the problem list fails to load. The refresh action is documented as working without sign-in, so a failed refresh points at the network or proxy rather than credentials. A failed submit points at credentials, and the README's remedy is to sign out and sign in again.

Editorial conclusion

Adopt Leetcode Editor if you already work in a JetBrains IDE and want to solve LeetCode problems with your own editor, debugger and keymaps. Skip it if you need a browser-free experience for company-specific question sets, or if you rely on LeetCode's web-only features. Before committing, install it from the JetBrains Marketplace, open File > Settings > Tools > LeetCode Plugin, pick leetcode.com or leetcode.cn, and verify that sign-in works for the site you use; the README notes that accounts for the two sites are independent.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. shuzijun/leetcode-editor on GitHub