IntelliJ: Claude Code Bug In .ijwb Directory With Bazel

Aug 4, 2025 by Kenji Nakamura 56 views

IntelliJ IDE Bug: Claude Code Opens in .ijwb Directory with Bazel Plugin

Hey guys,

I've run into a bit of a snag while using the Claude Code plugin with IntelliJ, and I wanted to share the details and see if anyone else has experienced this or has any insights. This article dives deep into a specific bug encountered while using the Claude Code plugin in IntelliJ IDEA with the Bazel plugin installed. We'll break down the issue, the steps to reproduce it, the expected and actual behavior, a workaround, and additional context to give you a complete picture. Let's get started!

Bug Description

The main bug I've encountered is that when the Bazel plugin for IntelliJ is installed (specifically version 2025.07.24.0.1-api-version-251 in my case), starting Claude Code in the IDE terminal kicks off in the .ijwb directory instead of the project root directory. This is a major pain because Claude Code can't find its license, and potentially other crucial project files, when it's running in the wrong directory. This issue significantly impacts the usability of the Claude Code plugin within IntelliJ IDEA when used in conjunction with Bazel. Imagine trying to debug your code or run tests, only to find that the environment is set up in the wrong directory, causing all sorts of pathing issues and preventing the tools from working correctly. It's like trying to build a house on the wrong foundation – everything else is going to be off. The .ijwb directory, which stands for IntelliJ Workspace Bazel, is where the Bazel plugin stores its configuration and metadata. It's not intended to be the working directory for running applications or tools like Claude Code. By starting in this directory, Claude Code is essentially isolated from the rest of the project, unable to access the necessary resources and configurations. This not only affects license validation but can also lead to problems with file resolution, dependency management, and other critical functionalities. The root cause of this issue appears to be related to how the Claude Code plugin determines the initial working directory when launched from the IntelliJ terminal with the Bazel plugin enabled. It seems to be inadvertently picking up the Bazel plugin's configuration directory instead of the project's root directory. This could be due to a misconfiguration in the plugin's startup script or a conflict in the way the Bazel plugin and Claude Code plugin interact with IntelliJ's terminal environment. Understanding the root cause is crucial for developing a permanent fix and preventing similar issues from arising in the future. In the meantime, the workaround described below provides a temporary solution, but it's not ideal for long-term use. Users need a seamless experience where the Claude Code plugin starts in the correct directory without manual intervention. This bug highlights the importance of thorough testing and integration testing, especially when different plugins and tools are used together within a complex IDE environment like IntelliJ IDEA. Ensuring that plugins play well together and do not interfere with each other's functionality is essential for maintaining a smooth and productive development workflow.

Steps to Reproduce

To reproduce this bug, follow these steps:

Install IntelliJ IDEA and install the Bazel plugin for IntelliJ. I'm using version 2025.07.24.0.1-api-version-251.
Start a new Bazel project.
Install Claude Code and the IntelliJ Claude Code [Beta] plugin (version 0.1.11-beta).
Click the Anthropic icon to start Claude Code in the IDE terminal.
Note that the current working directory (cwd) is incorrect. To elaborate on these steps, let's break them down further. First, ensure you have a clean installation of IntelliJ IDEA, which is crucial to avoid any potential conflicts from previous configurations or plugin versions. Once IntelliJ is set up, installing the Bazel plugin is the next key step. The Bazel plugin provides support for building and managing Bazel projects within IntelliJ, and it's the presence of this plugin that seems to trigger the bug. When you start a new Bazel project, IntelliJ will set up the necessary project structure and configuration files. This is where the .ijwb directory comes into play, as it's where the Bazel plugin stores its specific configurations. Next, installing Claude Code and its IntelliJ plugin is essential for bringing the AI-powered coding assistance into your IDE. Make sure you have the correct version of the plugin (0.1.11-beta in this case) to match the environment where the bug was initially observed. Finally, clicking the Anthropic icon is the trigger that launches Claude Code in the IDE terminal. This action should, ideally, start Claude Code in the project root directory, but the bug causes it to start in the .ijwb directory instead. Observing the cwd in the terminal will confirm whether the bug is present. By following these steps meticulously, you can reliably reproduce the bug and verify any potential fixes or workarounds. This detailed process is crucial for effective bug reporting and troubleshooting, as it allows developers to pinpoint the exact conditions under which the issue occurs. Reproducibility is key to resolving any software bug, as it allows developers to consistently observe the problem and test potential solutions.

Expected Behavior

Ideally, Claude Code should open with the current working directory set as the project root. This is crucial for Claude Code to correctly access project files, configurations, and other resources. When the current working directory is set to the project root, Claude Code can seamlessly interact with the project's file structure, understand the context of the code, and provide relevant suggestions and assistance. This behavior aligns with the standard practice of most command-line tools and IDE plugins, which assume that the working directory should be the project's top-level directory unless explicitly specified otherwise. Imagine you're working on a complex project with multiple modules and dependencies. If Claude Code starts in the wrong directory, it may not be able to locate the necessary files or understand the relationships between different parts of the codebase. This can lead to incorrect suggestions, broken code completion, and a generally frustrating experience. The expected behavior ensures that Claude Code has a clear and accurate view of the project, allowing it to function effectively as a coding assistant. Furthermore, starting in the project root is essential for tools like Claude Code to manage their own configurations and licenses. Many tools rely on relative paths to locate configuration files, and if the working directory is incorrect, these paths will be resolved incorrectly, leading to errors or unexpected behavior. In the case of Claude Code, the inability to find its license file is a direct consequence of starting in the wrong directory. By ensuring that Claude Code opens in the project root, developers can avoid these issues and focus on their coding tasks without having to worry about the underlying environment setup. This expectation is not just a matter of convenience; it's a fundamental requirement for Claude Code to function correctly and provide value to the user. A consistent and predictable working directory is essential for any development tool to integrate seamlessly into the development workflow.

Actual Behavior

In reality, Claude Code opens with the current working directory set as the .ijwb directory, which is the Bazel plugin's configuration directory. This is the core of the bug. This unexpected behavior has significant implications for the functionality of Claude Code within the IntelliJ environment. The .ijwb directory is specifically designed for the Bazel plugin to store its configuration files, caches, and other metadata. It's not intended to be the working directory for running applications or tools like Claude Code. When Claude Code starts in this directory, it's essentially isolated from the rest of the project. It can't see the project's source code, configuration files, or dependencies. This leads to a variety of problems, including the inability to locate its license file, as mentioned earlier. But the issues go beyond just license validation. Claude Code may also fail to provide accurate code suggestions, understand the project's structure, or run tests correctly. Imagine you're trying to use Claude Code to refactor a piece of code, but it can't see the other files in your project. It won't be able to provide context-aware suggestions, and you might end up introducing bugs or breaking dependencies. The actual behavior deviates significantly from the expected behavior, creating a barrier to the seamless integration of Claude Code into the development workflow. This discrepancy highlights the importance of addressing this bug to ensure that developers can use Claude Code effectively within IntelliJ IDEA with Bazel. The issue also underscores the need for careful testing of plugin integrations to identify and resolve conflicts before they impact users. Starting in the .ijwb directory essentially cripples Claude Code's ability to function as intended. It's like trying to navigate a city with a map that only shows a single building – you're missing the bigger picture and can't get where you need to go. The correct working directory is the project root, which provides the necessary context and access to resources for Claude Code to operate effectively.

Workaround

Luckily, there's a workaround, though it's a bit clunky:

Press ctrl+d twice to exit Claude Code.
Type cd .. to navigate to the actual project root.
Start Claude Code again by typing Claude.

While this workaround gets the job done, it's not ideal for a smooth workflow. It adds extra steps and can be a bit annoying to do every time you start Claude Code. This workaround, while functional, highlights the inconvenience caused by the bug. It requires users to manually intervene and correct the working directory, which disrupts the natural flow of development. Imagine having to perform these steps every time you want to use Claude Code – it quickly becomes tedious and time-consuming. The ideal solution is a permanent fix that eliminates the need for manual intervention. The workaround itself involves a few simple steps, but each step adds a bit of friction to the process. First, pressing ctrl+d twice is a quick way to exit Claude Code, ensuring that you're starting from a clean slate. Then, typing cd .. in the terminal navigates one directory level up, effectively moving from the .ijwb directory to its parent directory, which should be the project root. Finally, typing Claude restarts the Claude Code tool, but this time it will be running in the correct working directory. Although this workaround addresses the immediate issue, it's not a sustainable solution for long-term use. It's more of a temporary bandage than a cure. A proper fix would involve identifying the root cause of the bug and modifying either the Claude Code plugin or the Bazel plugin to ensure that Claude Code starts in the correct directory automatically. In the meantime, users will have to rely on this workaround to keep their development workflow running smoothly. The existence of this workaround demonstrates that the underlying functionality of Claude Code is sound, but the integration with IntelliJ and Bazel needs improvement. A seamless integration would make Claude Code a much more valuable tool for developers using these platforms.

Additional Context

Here's some additional context about my environment:

IntelliJ IDEA 2025.1.4.1 (Ultimate Edition)
Build #IU-251.27812.49, built on July 24, 2025
Source revision: 735cc3bd3c92f
Licensed to <Reducted> / Ilan Keshet
Subscription is active until November 6, 2025.
Runtime version: 21.0.7+9-b895.130 aarch64 (JCEF 122.1.9)
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Toolkit: sun.lwawt.macosx.LWCToolkit
macOS 15.5
Kotlin plugin: K2 mode
GC: G1 Young Generation, G1 Concurrent GC, G1 Old Generation
Memory: 8096M
Cores: 16
Metal Rendering is ON
Registry:
 ide.experimental.ui=true
 jvm.dfa.analysis.ui.security.analysis.window.was.shown=true
Non-Bundled Plugins:
 com.jetbrains.plugins.ini4idea (251.27812.54)
 com.ultrahob.zerolength.plugin (0.95)
 artsiomch.meson.syntax (203.1.0)
 org.jetbrains.plugins.go (251.27812.12)
 com.intellij.grazie.pro (0.3.388-251)
 info.fluffos.idea_bison (20230902.02)
 ir.msdehghan.plugins.ansible (1.0.0)
 name.kropp.intellij.makefile (251.25410.28)
 org.ermadan.kafkalytic (0.10.5)
 org.intellij.plugins.hcl (251.26927.39)
 PythonCore (251.27812.49)
 aws.toolkit.core (3.87.251)
 com.jetbrains.space (251.23774.318)
 org.jetbrains.plugins.ruby (251.27812.49)
 org.jetbrains.plugins.go-template (251.23774.318)
 fantom.codeowners (0.9.0)
 idea.goyacc (0.1.0)
 com.anthropic.code.plugin (0.1.11-beta)
 dev.meanmail.plugin.nginx-intellij-plugin (2025.14)
 Pythonid (251.27812.49)
 com.koxudaxi.pydantic (0.4.18)
 com.intellij.ml.llm (251.27812.49)
 net.seesharpsoft.intellij.plugins.csv (4.0.2)
 uk.co.ben-gibson.remote.repository.mapper (4.5.2)
 mobi.hsz.idea.gitignore (4.5.6)
 amazon.q (3.87.251)
 com.intellij.bigdatatools.core (251.27812.49)
 izhangzhihao.rainbow.brackets.lite (1.3.0)
 org.intellij.scala (2025.1.32)
 com.google.idea.bazel.ijwb (2025.07.24.0.1-api-version-251)
 com.github.copilot (1.5.52-243)
 aws.toolkit (3.87.251)
Kotlin: 251.27812.49-IJ

I'm running IntelliJ IDEA 2025.1.4.1 (Ultimate Edition) on macOS 15.5. I'm also using the Claude Code [Beta] IntelliJ plugin version 0.1.11-beta, Claude CLI version 1.0.67 (Claude Code), and Bazel plugin version 2025.07.24.0.1-api-version-251. This detailed environment information is crucial for developers to replicate the bug and identify the potential causes. The specific versions of IntelliJ IDEA, the Claude Code plugin, the Bazel plugin, and the operating system can all play a role in the occurrence of the bug. For instance, the bug might be specific to a particular version of the Bazel plugin or a combination of plugin versions. Providing this information allows developers to focus their investigation on the relevant parts of the codebase and narrow down the potential sources of the issue. The list of non-bundled plugins is also valuable, as it provides context about the other tools and extensions that are installed in the IDE. Conflicts between plugins can sometimes lead to unexpected behavior, so knowing which plugins are present can help identify potential interactions. The additional details about the runtime environment, such as the Java version, the VM, and the memory settings, can also be relevant in certain cases. Performance issues or compatibility problems with specific Java versions could potentially contribute to the bug. By providing a comprehensive overview of the environment, bug reporters can significantly aid the debugging process and increase the likelihood of a successful resolution. This level of detail demonstrates a commitment to thoroughness and a desire to help developers fix the problem as quickly as possible. It also highlights the importance of collecting and sharing detailed environment information when reporting bugs in complex software systems.

This screenshot shows the issue in action. You can see that the terminal's current working directory is set to .ijwb instead of the project root. Visual evidence like this can be incredibly helpful for developers trying to understand and fix a bug. A screenshot provides a clear and immediate representation of the problem, eliminating any ambiguity or misinterpretations that might arise from textual descriptions alone. In this case, the screenshot directly demonstrates that the terminal's current working directory is incorrectly set to .ijwb instead of the project root. This visual confirmation reinforces the bug description and makes it easier for developers to grasp the issue at a glance. Screenshots are particularly valuable when dealing with user interface bugs or issues related to environment configuration, as they capture the exact state of the system at the time the bug occurred. They can also reveal subtle details that might be missed in a textual description, such as error messages, file paths, or unexpected visual elements. In addition to showing the symptoms of the bug, screenshots can also provide context about the user's workflow and the steps they took to reproduce the issue. This can help developers understand how the bug is triggered and identify the sequence of events that leads to the problem. When reporting bugs, it's always a good practice to include screenshots or screen recordings whenever possible, as they can significantly enhance the clarity and effectiveness of the bug report. Visual evidence can often speak louder than words and help developers quickly diagnose and resolve issues. A well-chosen screenshot can save developers time and effort by providing a clear and concise representation of the problem.

Hopefully, this detailed report helps in getting this bug fixed! Let me know if you guys have any questions or need more info.