Mojo Plugin for IntelliJ & PyCharm Not Working: SDK, Autocomplete, Highlighting and Crash Fixes

You installed the Mojo plugin. The IDE confirmed it. You restarted. And now — nothing. No highlighting, no completion, no SDK binding. The editor just stares back at you treating .mojo files like plain text from 2004. This page is specifically for that state: post-install, pre-functional, figuring out what broke and whether it’s fixable at all.

Mojo’s JetBrains integration is early-stage. That’s not a complaint — it’s a prerequisite for understanding every issue on this page. Some failures have clean fixes. Others are architectural gaps in the current toolchain. Both are covered here, without padding.
TL;DR

• The Mojo JetBrains plugin is experimental — many IDE features are partially or not yet implemented
• SDK detection fails most often because the plugin doesn’t scan non-standard install paths automatically
• Syntax highlighting works only when the file type association and plugin activation are both confirmed
• Autocomplete depends on LSP — if the language server isn’t running, completion is dead
• File indexing failures usually trace back to incorrect project SDK or missing file type mapping
• Crashes and freezes are often caused by LSP restarts under load or plugin conflicts with IDE indexing threads

Mojo Plugin Installed but Nothing Works in IntelliJ or PyCharm

Symptom. Plugin shows as “Enabled” in the plugin manager. No error on install. IDE restarted. But the editor has zero Mojo awareness — no gutter icons, no file type recognition, no language features, nothing in the Project Structure that references Mojo.

Root Cause. JetBrains plugin activation isn’t just about the plugin being present — it requires the plugin to successfully register its extension points with the IDE’s component system at startup. If that registration fails silently (missing dependency, incompatible IDE build number, corrupted plugin cache), the plugin sits in limbo: installed but inert.

# Plugin appears in list but IDE has no Mojo awareness
# Check idea.log for silent failures at startup

# Linux/macOS
cat ~/.config/JetBrains/IntelliJIdea2024.x/log/idea.log | grep -i mojo

# Windows
type %APPDATA%JetBrainsIntelliJIdea2024.xlogidea.log | findstr /i mojo

# Look for:
# ERROR - PluginException: Cannot load class MojoLanguage
# WARN - Extension point registration failed for com.mojo.*
# INFO - Plugin 'Mojo' loaded — this means it DID register correctly

Why it happens. The Mojo plugin targets specific IDE build ranges. If your IntelliJ or PyCharm build is outside that range — either too old or a very recent EAP build — the plugin loads but its internal components fail to wire up. The plugin manager doesn’t surface this as an error.

Fixes.

1. Go to Help → Find Action → “Invalidate Caches” → tick all options → restart. This clears corrupted plugin state from previous installs.
2. Check the plugin page on JetBrains Marketplace for the exact supported IDE version range. If your build number falls outside it, either downgrade the IDE or wait for a plugin update.
3. Manually verify extension registration: Help → Diagnostic Tools → Debug Log Settings, add #com.mojo, restart, reproduce, check idea.log.

Edge Case. PyCharm Community vs Professional matters here. Some JetBrains plugins register extension points that only exist in the Professional edition. If you’re on Community and certain features never appear, that’s not a bug — it’s a missing platform API.

Mojo SDK Not Detected or Not Configured in JetBrains IDEs

Symptom. The IDE shows “No SDK configured” or “SDK not found” for Mojo projects. Run configurations fail immediately. The editor may show red underlines on every import or module reference.

Root Cause. JetBrains SDK detection relies on the plugin providing a path resolver that scans known install locations. Mojo doesn’t install to standard locations by default — it uses Magic package manager, which drops binaries into user-specific directories. If the plugin’s path resolver doesn’t know where to look, auto-detection returns empty.

# Where Mojo actually installs (via Magic)
# These paths are NOT in the JetBrains default SDK scan list

# macOS
~/.modular/pkg/packages.modular.com_mojo/

# Linux
~/.modular/pkg/packages.modular.com_mojo/

# Verify the binary exists before configuring SDK
which mojo
# OR
~/.modular/bin/mojo --version

# If 'which mojo' returns nothing but mojo works in terminal:
echo $PATH
# PATH modification from Magic may not propagate to IDE's process environment

Proof. Open a terminal launched from your IDE (not your system terminal). Run mojo --version. If it fails there but works in a standalone terminal, the IDE’s inherited environment is missing the PATH entry that Magic injected into your shell profile.

Fixes.

1. Manual SDK path configuration: Go to File → Project Structure → SDKs → Add SDK → Mojo SDK. Point it directly to the Mojo binary: ~/.modular/bin/mojo. The plugin should accept this and validate the path.
2. Fix IDE environment inheritance: On macOS, launch IntelliJ or PyCharm from the terminal (open -a "IntelliJ IDEA" . or pycharm .) so it inherits your shell’s PATH, including Magic’s modifications.
3. Add the path explicitly in IDE settings: Help → Edit Custom Properties (or idea.properties) — some teams hardcode mojo.sdk.path=/Users/you/.modular/bin/mojo as a workaround when environment inheritance is unreliable.

Edge Case. If you installed Mojo via a system package manager rather than Magic, the binary location differs. The plugin may or may not recognize it — test with the manual path approach regardless of install method.

No Syntax Highlighting or Code Intelligence in Mojo Files

Symptom. Opening a .mojo or .🔥 file shows flat, uncolored text. No keywords highlighted, no string coloring, no structure. The file type indicator in the bottom status bar shows “Plain Text” or an unknown file type icon.

Root Cause. Two independent systems must both be working for syntax highlighting to appear: the file type association (telling the IDE this is a Mojo file, not plain text) and the lexer/grammar bundle the plugin ships. If either registration failed at plugin load time, you get plain text regardless of what’s in the file.

# Check file type association via IDE settings
# Settings → Editor → File Types → look for "Mojo" in the list

# If Mojo is absent from the list entirely:
# → Plugin failed to register its file type extension point

# If Mojo IS in the list but .mojo extension is missing:
# → Add it manually: Settings → Editor → File Types → Mojo → add *.mojo

# Verify the file type from within the editor:
# Bottom status bar → click file type indicator (right side, says "Plain Text")
# → "Associate file type" → select Mojo

# Check for competing registrations:
# Settings → Editor → File Types → search for *.mojo across ALL types
# Another plugin may have claimed that extension

Fixes.

1. Go to Settings → Editor → File Types. Find “Mojo” in the list. If it’s there but missing the *.mojo pattern, add it manually. If “Mojo” isn’t in the list at all, the plugin’s file type registration failed — restart with cache invalidation first.
2. Check for extension conflicts. If another plugin registered *.mojo (unlikely but possible), the Mojo plugin loses. Find it under File Types and remove the conflicting pattern.
3. Verify the plugin is actually enabled for the current project: File → Settings → Plugins — plugin state is global, but some IDEs allow per-project overrides via workspace settings.

Edge Case. The .🔥 extension (the emoji variant) requires UTF-8 filename support from the OS and the IDE’s virtual file system layer. On Windows with non-UTF-8 locale settings, this extension may never register correctly. Stick to .mojo for now on Windows systems.

Mojo Autocomplete and Suggestions Not Working

Symptom. Pressing the completion shortcut (Ctrl+Space / Cmd+Space) in a .mojo file produces either nothing, or only generic text suggestions with no type awareness. No function signatures, no parameter hints, no import suggestions.

Root Cause. Mojo’s JetBrains plugin relies on the Mojo Language Server (LSP) for semantic completion. The plugin acts as an LSP client — it launches the language server process, pipes editor events to it, and renders what comes back. If the language server process isn’t running, or the IPC channel between plugin and server is broken, autocomplete produces nothing meaningful.

# Check if the Mojo language server process is running
# macOS / Linux
ps aux | grep mojo-lsp
# OR
ps aux | grep modular

# Expected output if running:
# user 1234 0.0 0.2 mojo-lsp-server --stdio

# If nothing appears: language server failed to start
# Common reasons:
# 1. Binary not found (SDK path wrong)
# 2. Port conflict or stdio pipe failure
# 3. Server crashed and plugin didn't restart it

# Check LSP logs in JetBrains
# Help → Diagnostic Tools → LSP → look for Mojo server entry
# OR check idea.log for lines containing "LSP" + "mojo"

Proof. In Help → Diagnostic Tools → LSP (available in recent IDE versions), you can see registered language servers and their status. A running Mojo LSP shows as “Connected.” Anything else — “Starting,” “Stopped,” “Error” — explains the missing completion.

Fixes.

1. Confirm the SDK path is set correctly (see H2 above). The language server binary is inside the Mojo SDK directory — a wrong SDK path means the plugin can’t find the server to launch it.
2. Restart the language server without full IDE restart: File → Invalidate Caches is overkill here. Instead, close and reopen the project, which triggers a fresh LSP session initialization.
3. Check available memory. The Mojo LSP is not lightweight. If the IDE is already consuming most of available RAM, the server process may fail to start or crash immediately. Increase IDE heap in Help → Change Memory Settings.

Edge Case. Even with LSP running correctly, completion coverage in the current plugin version is incomplete. Standard library functions may not appear. This isn’t a configuration problem — it’s a coverage gap in the current release. Check the plugin changelog for LSP feature status before spending time debugging what may be a known limitation.

Mojo Files Not Recognized or Project Not Indexed

Symptom. The IDE doesn’t index .mojo files. “Find in Files” doesn’t search them. The Project view may show them with a generic icon. Navigate to Symbol returns nothing for Mojo-defined names. The file is essentially invisible to IDE tooling.

Root Cause. JetBrains indexing works by file type. Only files with registered, known types participate in the symbol index, “Find in Files” scope, and project structure analysis. If .mojo isn’t registered as a first-class language file type (or if it is registered but the indexer extension the plugin provides failed to load), the IDE skips those files during project scan.

# Diagnose indexing state
# Check if .mojo files appear in project search scope

# In IDE: Edit → Find → Find in Files
# Scope: "Project Files" → search for a known symbol in your .mojo file
# If it doesn't appear → files are excluded from index

# Check excluded folders (common gotcha):
# File → Project Structure → Modules → Sources tab
# If the directory containing .mojo files is marked as "Excluded" (red)
# → change it to "Sources" (blue)

# Force re-index:
# Right-click project root → "Repair IDE" (newer versions)
# OR: Help → Find Action → "Rescan Project Indexes"

# Check that the SDK is set at module level, not just project level:
# File → Project Structure → Modules → Dependencies tab
# SDK should appear here as a module dependency

Fixes.

1. Verify the source root configuration: File → Project Structure → Modules. The directory containing your Mojo source files must be marked as a Sources root (blue folder icon). If it’s excluded or unmarked, the indexer never touches it.
2. Force full re-index: Help → Find Action → search “Rescan Project Indexes” or use Invalidate Caches → Just Restart (without clearing download caches, to save time).
3. Verify file type registration as described in the highlighting section. Indexing and highlighting both depend on the same file type registration — fixing one usually fixes the other.

Edge Case. Large Mojo projects may hit indexing timeouts. The IDE’s default indexing thread budget is tuned for Java/Kotlin-scale projects. If you have thousands of .mojo files, the initial index may appear to stall. Check the background task indicator — it may still be running, just slowly.

Mojo Plugin Crashes, Freezes, or Slows Down JetBrains IDE

Symptom. The IDE becomes sluggish after opening Mojo files. Typing lags by 200–500ms. The IDE freezes periodically for 2–10 seconds. In worse cases, the IDE crashes entirely with an OOM error or an unhandled exception from a Mojo plugin component.

Root Cause. Three independent failure modes produce this cluster of symptoms. First: the LSP server process consuming excessive CPU during analysis (common on first open, when it indexes the full standard library). Second: the plugin’s file watcher triggering re-analysis on every keystroke without debouncing — saturating the IDE’s EDT (Event Dispatch Thread). Third: memory pressure from two heavyweight processes (IDE + LSP server) competing on systems with less than 16GB RAM.

# Identify which process is consuming resources

# macOS
top -o cpu | head -20
# Look for: idea, mojo-lsp-server, java (JVM for IDE)

# Linux
htop
# Filter by process name: 'F' key → search 'mojo' or 'idea'

# Typical healthy state:
# idea (JVM): 2–8% CPU when idle, 20–40% during active typing
# mojo-lsp-server: <5% CPU when idle, spike to 30–60% on file open # Problematic state: # mojo-lsp-server: sustained 80–100% CPU → runaway analysis loop # java (IDE): 100% CPU + UI freeze → EDT blocked by plugin code # Both: combined memory > system RAM → swap thrashing → freeze

# Check IDE freeze reports:
# Help → Diagnostic Tools → "Analyze IDE Freezes"
# Freeze reports show which thread/component caused the hang

Fixes.

1. Increase IDE heap allocation: Help → Change Memory Settings. For a system with 16GB RAM, set IDE heap to 4096MB minimum. This reduces GC pressure and prevents the freeze-on-collection pattern.
2. Disable plugin features you’re not using: If the plugin offers toggles for background analysis, semantic highlighting, or real-time error detection — disable non-essential ones. Reducing the LSP call frequency is the fastest way to recover IDE responsiveness.
3. Restart the LSP server if it’s in a runaway state: Close all Mojo files (removing them from the editor’s open file set), wait for LSP CPU usage to drop, then reopen. Some LSP implementations enter analysis loops on specific syntax patterns — reopening forces a fresh parse.

Edge Case. Plugin conflicts with other installed JetBrains plugins are underreported but real. If you have plugins that hook into file save events, code analysis pipelines, or LSP infrastructure (some third-party AI coding tools do this), they can interact badly with Mojo’s LSP client. Disable third-party plugins one by one to isolate.

Cannot Run Mojo Files or Run Configuration Is Missing

Symptom. No “Run” gutter icon appears next to fn main(). The Run menu shows no Mojo-specific configuration options. Right-clicking a .mojo file offers no “Run” option. Manually created run configurations fail immediately without a useful error message.

Root Cause. JetBrains run configurations for language plugins depend on the SDK being correctly bound at both project and module level, and on the plugin providing a RunConfigurationProducer that recognizes Mojo entry points. If the SDK isn’t configured or the plugin’s run producer failed to register, the IDE has no mechanism for generating run configurations automatically.

# Manual run configuration setup when automatic detection fails

# Step 1: Verify SDK is bound
# File → Project Structure → Project → Project SDK → should show Mojo

# Step 2: Create run config manually
# Run → Edit Configurations → + → look for "Mojo" type
# If "Mojo" type is absent → plugin run producer not registered
# Workaround: use "Shell Script" configuration type

# Shell Script workaround config:
# Script path: /bin/bash (or /usr/bin/env)
# Script options: -c "~/.modular/bin/mojo run $FilePath$"
# Working directory: $ProjectFileDir$

# This bypasses the plugin's run infrastructure entirely
# and executes mojo directly — useful for verifying code works
# while IDE integration is broken

# Check output for errors:
# ~/.modular/bin/mojo run path/to/file.mojo
# Run this in terminal first before creating IDE config

Fixes.

1. Set up the SDK first (File → Project Structure). Run configurations frequently auto-populate once the SDK is correctly bound — try reopening the project before manually creating configs.
2. Use the Shell Script workaround above as a functional bridge. It’s not elegant, but it gets code executing while IDE integration stabilizes.
3. Check the Mojo plugin’s GitHub issues for run configuration bugs specific to your IDE version. This is an area where the plugin has had several regressions across releases.

Edge Case. On Windows, path separators in the script options field need to be forward slashes or properly escaped. The $FilePath$ macro outputs OS-native separators, which can break the mojo run command if Mojo’s binary expects Unix-style paths.

Mojo LSP Not Connecting or Language Server Fails to Start

Symptom. The IDE shows “Language server is starting…” indefinitely, or the LSP status indicator shows a red/error state. Hovering over it reveals a connection error or timeout. All semantic features — completion, diagnostics, go-to-definition — are dead.

Root Cause. The LSP handshake between the JetBrains plugin and the Mojo language server uses stdio (standard input/output pipes). If the server binary can’t be found, exits on startup, or produces unexpected output before the JSON-RPC handshake completes, the plugin marks the connection as failed and stops retrying.

# Test language server startup manually outside the IDE
# This isolates whether the problem is in the binary or the plugin

# Run the server in stdio mode directly:
~/.modular/bin/mojo-lsp-server --stdio

# Expected: process starts and waits silently for JSON-RPC input
# Problem indicators:
# - Process exits immediately → binary issue or missing dependency
# - Error output before waiting → config or path problem
# - "command not found" → SDK path wrong, binary not at expected location

# Send a minimal LSP initialize request to test the handshake:
echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"processId":null,"rootUri":null,"capabilities":{}}}' | ~/.modular/bin/mojo-lsp-server --stdio

# Healthy response starts with:
# Content-Length: NNN
# {"jsonrpc":"2.0","id":1,"result":{"capabilities":{...}}}

# If you get nothing or an error → LSP binary is the problem, not the plugin

Fixes.

1. Run the manual test above. If the binary works in isolation, the problem is in how the plugin launches it (wrong path, wrong arguments). Check plugin settings for LSP server path configuration.
2. Check file permissions on the Mojo binary: ls -la ~/.modular/bin/mojo-lsp-server. It needs execute permission. Magic usually handles this, but manual installs or permission changes can strip it.
3. If the server starts but crashes immediately, check system logs (dmesg on Linux, Console.app on macOS) for OOM kills or security software blocking the binary.

Edge Case. Some corporate environments run endpoint security software that blocks unsigned or newly downloaded binaries from executing. If Mojo was recently updated via Magic, the new binary may be quarantined. Whitelist the ~/.modular/ directory in your security software if this applies.

FAQ

Q: Is the Mojo JetBrains plugin production-ready?
No. As of current releases, it’s an early-stage integration. Core features like full autocomplete, reliable SDK detection, and run configuration automation are works in progress. Treat it as a developer preview with partial functionality.

Q: Does the plugin work the same in IntelliJ IDEA and PyCharm?
Mostly. The plugin targets both IDEs, but PyCharm has tighter Python tooling integration that can create conflicts with Mojo’s environment detection. IntelliJ IDEA (especially the Community edition) provides a cleaner baseline for Mojo if you’re running into PyCharm-specific issues.

Q: Why does nothing work after a Mojo update via Magic?
Magic updates the Mojo binary and SDK in-place. The IDE caches the old SDK path and sometimes the old binary hash. After any Mojo version update, invalidate IDE caches and re-validate the SDK path in Project Structure.

Q: Can I use the Mojo plugin alongside the Python plugin in PyCharm?
Yes, but with caveats. Both plugins register LSP clients and file system watchers. On resource-constrained systems, having both active simultaneously increases freeze frequency. If you’re doing Mojo-only work, consider disabling the Python plugin temporarily.

Q: The plugin works on my colleague’s machine but not mine — same IDE version, same Mojo version. Why?
Environment divergence is the most common cause: different shell profiles means different PATH, different Magic install locations, or different IDE plugin cache states. Compare echo $PATH output from terminals launched by the IDE on both machines. Also compare ~/.modular/ directory structure.

Q: How do I report a Mojo plugin bug effectively?
Include: IDE version (Help → About), plugin version (Settings → Plugins → Mojo), Mojo version (mojo --version), OS and version, the relevant section of idea.log, and steps to reproduce. The plugin’s GitHub issues page is the right place — not the Mojo language forums, which track language issues separately from IDE tooling.

Q: Is there a VS Code alternative that works better for Mojo right now?
Yes. The Mojo VS Code extension has more active development and a more complete LSP integration at this stage. If IDE features are blocking your productivity rather than just being inconvenient, VS Code with the official Mojo extension is the more functional option currently. The JetBrains plugin is catching up but isn’t at feature parity.

Conclusion

Most Mojo plugin failures in JetBrains IDEs fall into three buckets: environment issues (SDK path, PATH inheritance), plugin registration failures (caches, build compatibility), and LSP connectivity problems (server not starting, connection timing out). The fixes follow that same order of diagnosis — environment first, plugin state second, LSP third.

What won’t be fixed by any configuration change: features the plugin simply hasn’t implemented yet. Full autocomplete coverage, complete run configuration automation, and deep project analysis are on the roadmap but not fully shipped. Knowing which problems are configuration versus capability gaps saves a lot of time that would otherwise go into debugging something unfixable from the user side.

The practical working setup right now: manually configure the SDK path, verify the LSP binary starts in isolation before relying on the IDE to launch it, and use a shell script run configuration as a fallback when the native run producer doesn’t appear. That combination covers the majority of daily workflow needs while the plugin matures.

Keep the plugin updated — this is an active development area and several of the issues described here have patch releases shipping regularly. Check the JetBrains Marketplace plugin page changelog before spending significant time on a bug that may already be fixed in a newer version.