[Solved]Pycharm remote debugging local file not updating


Tried to restart PyCharm and everything's alright.


Hi, I'm using Pycharm 2016.3 Professional edition's remote debugging. However, something weird happened.

After I modified local files and upload to remote servers, I tried to remote debugging using the remote interpreter. But when I stepped into other function inside other files of my project, I found that the files were located at local path such as ~/.PyCharm2016.3/system/remote_sources/-1117781397/-12687924/path/to/my/file but it was not updated to the newest.

To make sure I did sync files to my remote server, I ssh to the remote server and make sure that the files have changed correctly.

Also, I tried to use the remote interpreter to run my code, whose result was correct which differed from what using remote debug.

So I want to know is there something wrong or do I have a method to update local caches of remote files? Please forgive my poor English and I am looking forward to some help.


I've been seeing this repeatedly with both profiling and debugging, using PyCharm Professional 2018.3.

After manually uploading and/or synchronizing via the Deployment menu, both on individual files and the entire project, the debugger and profiler still run old code.

I somehow managed to get the profiler running current code, but now the debugger is using old code.  It'll pull up local files, but line numbers are mismatched and not all breakpoints get set.

BTW, the settings between the run configuration (working directory, script path) and deployment (root path and mappings) are non-intuitive and not obviously connected.


This problem still exists with 2020.1.4 Professional! 

This is crazy annoying. Resetting the interpreter helps only for a microsecond, after one run it is back to the same old problem of debugging old cached files. 


Hi, the issue is still actual in release PyCharm Professional 2019.1. I configured new working environment, integrated with Vagrant. The only mapping is the whole my local workspace and the workspace on remote (vagrant) instance.

When I make changes to some modules I see the update on remote but debugger points me on cached version in "remote_sources" which is outdated. I cleaned the cache, restarted PyCharm, so the modules were updated but on next change I reveal the same thing.

Please advice if there is any config that worth to look at


Are you, by any chance, working on your own python package, which you installed using setup.py ?


I couldn't reproduce it. Did you install your modules as editable to your interpreter?

remote_sources are the packages installed to your project interpreter and downloaded by PyCharm to have a local copy of them.


This problem still exists with 2020.2Professional! 

This is crazy annoying. Resetting the interpreter helps only for a microsecond, after one run it is back to the same old problem of debugging old cached files. 


Why is this marked as solved?
This is happening in 2017.3.
It runs the correct code but debugs old, wrong code, in remote_sources.


Having the same problem with WSL. I'm trying to modify a library that's not meshing well with my code, but the debugger uses a cached version of my library after I edit it while using the debugger. No fix found yet?


I am having similar issues debugging locally with the latest version 2019.1.3 CE. Everything was fine until I found some bug in my code. I edited the file by adding some lines. Now, the debugger stops in the right breakpoints but follows the logic of the old code. I tried "File>Invalidate Caches / Restart ..." But this hasn't solve the problem at all. I tried adding multiple breakpoints but the debugger still follows the old file's logic. Any solutions?


Running Professional 2019.2 on Ubuntu 16, having the exact same problem. This issue is *not* solved and should not be marked as such.


Greetings from 2019/12/30, the problem is STILL unsolved. I stumbled into this issue with weird server behavior and took me a while to question myself what have I done wrong. 

Basically the same workflow like the others and also read about the workaround to sync the cache file myself as there are multiple "-random_numbers" folders under the ".PyCharm2019.3/system/remote_sources/-612333121/-23454112" route. (By the way, is that part of the problem here? Might be abnormally generating too many cache folders here?)


Please fix this the mighty team of PyCharm, remote debugging without tool/ with faulty tool is a nightmare.

Thanks in advance.




Bbc-abc Did you create a ticket for this issue, I also have an issue in 2020.1 where the debugger is using an old cached version of the files that are not updated. I can see that docker-compose is refreshing the files fine but the Pycharm debugger is caching the files at the time docker-compose last built.

Please post any valid tickets.


Maxime Renaud What is #2430827? Have you filed a new issue?


PyCharm 2021.1 (Professional Edition)
Build #PY-211.6693.115, built on April 6, 2021
VM: Dynamic Code Evolution 64-Bit Server VM by JetBrains s.r.o.
Linux 5.8.0-50-generic
Current Desktop: ubuntu:GNOME

Im not one to usually complain, I love everything else about this product but this is STILL happening and every subsequent update is making it worse! I have been putting up with it each version by simply exiting the incorrect cached JavaScript file and continuing to work but as of this most recent version the IDE editing window will bring up the incorrect cached copy of the JavaScript file (as it have for several years now) where i have placed the breakpoint but NOW it crashes the entire editing window meaning I have to completely quit and restart PyCharm. I have tried every fix on this thread and I am yet to see a competent answer or setting change that stops the IDE from bringing up this cached file. Someone please explain this and make it stop happening. 


Jooyounglee93 Here's a related issue https://youtrack.jetbrains.com/issue/PY-49805 (currently open)

I would appreciate if you post the steps to reproduce the issue, starting from creating a minimal project. Unfortunately, it appeared to be not very easy to reproduce the issue in the test environment. And, the absence of clear steps is what's holding this issue from resolving, I think.


I have deleted (or moved) it previously. It did not help.

This is actually what causes the issue.

If you delete the remote sources, they are still in listed in some index, but the files are missing.
PyCharm then does not redownload because they are still in the index.
I think the index is one of these files (I grepped them):


But I was not brave enough to delete them yet.


Manually removing ~/Library/Caches/PyCharm2018.3/remote_sources/* and restarting seems to have updated at least one file, but other subsequent execution is using out-of-date files.



Please attach a screenshot of your Run/Debug configuration and another one showing the problem.


Hi Sergey,


Attached the screenshot with run/debug configuration. Unfortunately I can't share the screenshot with code that represents the issue.

The workflow is:

  1. I modify code - add few lines of code in one module
  2. Add breakpoint for debug
  3. Check the file remotely in Vagrant, it has the change after file is saved
  4. Run Debug from PyCharm
  5. Debugger stops on the breakpoint, but shows me cached version of the module (not the module where I added the breakpoint). this cached version doesn't contain the newly added lines of code so the line highlighted is incorrect

Debugger points me on file in this location: /Users/petro.zdeb/Library/Caches/PyCharm2019.1/remote_sources/-281485427/-1651854169/tests/test_db_wrappers.py


Hmmm, that's interesting.

Do you have any deployment configurations for the project? In particular, do you deploy your project files to that vagrant box?

Please share another screenshot showing your Project Interpreter and its Path mappings.


By the way, does it happen only with pytests/certain files or you can reproduce it with some test file and minimum code?


Hmm, seems it happens only for run with pytest. When I run the debugger in normal Python mode and Vagrant, it allows me to debug original file (not the cache)


I had a similar issue. I was debugging a python application installed (non editable) inside of a docker container.

I started the debugger by right-clicking on one of the files on my host machine.

What I did not expect (even though I should have), the imports then referenced the installed files within my docker container and not the changed ones on my host machine.

I resolved it by:

-> rebuilding the docker container & invalidating my pycharm cache

Thans @Sergey Karpov for pointing me in the right direction (remote_sources).



@Andrey-Resler I am not using remote debugging, I am using Local debugging, hence I have nothing to upload anywhere. I already tried manually removing some files from ".idea/" folder but no success so far. Funny enough, the same is happening now with Pycharm 2018.1.3 CE, which makes me think that 2019.1.3 corrupted the project files some how but I don't know which one. I am trying now to get a new fresh project and copying the code manually.


@Andrey-Resler Yes, I did. Unfortunately that didn't work either.

I found a hackey solution that might be useful for people. Basically, edit the temporary file. Then open the terminal and run the script I posted below. The idea is that you replace the actual library file in your filesystem with the temporary one you're editing after you make your modifications. It solves the most annoying problems and makes the workflow as you'd expect it for the most part. This is WSL specific solution, but I'd expect if you're working on a remote server the same idea would apply. Make a script that transfers the edited file to the remote before you launch your debugger every time and you should be golden.

The problem I'm running into now is that I can't open projects that are located purely in WSL, and not on my /mnt/c/ directory. VSCODE seems to work, and I can call pycharm on anything in /mnt/c, but not in WSL. This makes it so that even though I can edit through some temporary files and continue with my debugger remotely, as soon as I try to get into a file that isn't in my temporary directory the debugger stops :(. Any suggestions on how to handle that? If so, that would essentially provide a workaround for this bug in practice until a more concrete fix is presented



# Used to push modified library files to remote_resources
# Will allow faster debugging of external libraries with pycharm



# Files to forward


# Copy over the files

cp $pycharm$file1 $bilby


I meet this problem too,please solve it.


I have the same problem, with Phpstorm, and between a local copy on a Windows system and a remote copy on a Centos 7.x system through Vagrant. Line numbers are out of sync, even though the comparison between local and remote files indicate no differences.

Please fix this.


Sorry, forgot to mention: Phpstorm 2019.2 on Windows 10, with Vagrant running Virtual Box. The fact that the same problem appears across two different Idea-based applications and different environments strongly suggests the problem lies with the platform.


One more comment: the trouble may be due to a (my) misconfiguraton of the Deployment package.


Running Professional 2019.1.3 on MacOS10.14, having the exact same problem. This issue is *not* solved and should not be marked as such.