Slow session startup (now w/ Runtime startup diagnostics)

[codeswitching]

I'm taking @juliasilge 's advice and opening a new discussion for my persistent slow startup issue.

R 4.5.1 loads by default and usually takes several minutes. Once the first R session finally loads, additional R sessions start quickly (~6 seconds). I notice that Positron always seems to spend a long time discovering Python interpreters, even after an R session starts.

Windows Defender exceptions

In case this has anything to do with Windows Defender, here are the permissions. No additional permissions are allowed by my IT policy.

Runtime Startup Diagnostics

Runtime Startup Diagnostics.txt

[jmcphers]

Thanks for the diagnostics report! The part that really stands out is that it's taking almost a full minute to activate the Python subsystem:

Name	Timestamp	Delta	Total
code/positron/runtimeStartup/extensionActivated/positron.positron-r	1772732259032	2	30412
code/positron/positron.positron-supervisor/started	1772732259032	0	30412
code/positron/positron.positron-supervisor/ready	1772732262985	3953	34365
code/positron/runtimeStartup/extensionActivated/ms-python.python	1772732319958	56973	91338

I'm not sure why this would be (perhaps it's hitting network connections or drives). Would you be willing to try disabling it and restarting Positron to see if it is indeed the issue? You can do this by typing @builtin python to the Extensions pane as follows and then selecting the "Disable" option from the gear:

If that does improve things, we can dig more into why it's so slow to start up.

If that doesn't improve things, could you share the results of the Developer: Startup Performance command? (it looks like a lot of time is being spent activating extensions here so it may be other extension(s) delaying activation of the ones needed)

[codeswitching]

That definitely helps, cutting the time to first runtime in half (~1 minute):

Runtime Startup Diagnostics.txt

If I re-enable the Python extensions, here is the Runtime Diagnostic and the Startup Performance:

Runtime Startup Diagnostics - with Python enabled.txt

Startup Performance.txt

Btw, every so often, Positron is unable to discover any Python interpreters at all. Reloading Positron usually resolves this.

[jmcphers]

Thanks, that's very helpful!

With Python enabled, can you grab the entire contents of the "Python Language Pack" logs for us? (for brevity, the diagnostics report only shows the last 50 lines). I'd love to know why it is taking an ENTIRE MINUTE to start up. That's way too long.

We've also reproduced the "failed to discover any Python interpreters" issue sporadically in our tests and are investigating. If you hit this in the future, can you see whether you are able to open the New Folder from Template dialog? (seems unrelated but isn't!)

[codeswitching]

I set the logging level to 'debug' - definitely some relevant-seeming errors in here:

Python Language Pack.log

[jmcphers]

I've opened a couple of issues on our side to track:

Shouldn't need to wait for Python to start R - #12349
Python takes 1 minute to start - #12349

[ldecicco-USGS]

This feels exactly like:
rstudio/rstudio#15609

It takes me well over a minute to get Positron started. If I switch folders after it's open that cuts the time about in half. Restarting Positron takes goes back to >1 minute:

Initial open:
Runtime_diagnostics.txt

Changing folder:
runtime_changing_folders.txt

Restart Positron:
Runtime_restart.txt

[juliasilge]

Thanks for sharing these logs!

It looks like in your case, positron-reticulate activation is the main bottleneck, taking ~57 sec. We made a fix that addresses this in #12338, which is currently available in the daily builds and will be released about Monday.

The secondary bottleneck in your case is the third party Julia extension ntluong95.positron-julia, which is taking about ~28 sec to activate. If you don't need that extension all the time, you might consider deactivating it. I believe the work we have logged in #12591 would alleviate this, either way, although there would be tradeoffs from us implementing that.

[sawelch-NIVA]

I think I'm having the same issue... startup times seems to be very inconsistent, but it always takes longer than it should do. In my case, I disabled everything associated with Python, and most of my 3rd-party extensions.
Runtime Startup Diagnostics - R Positronb No Python.txt

If I'm reading the runtime table properly, the slowest step by far is:

Name	Timestamp	Delta	Total
code/positron/runtimeSessionWillStart/r-7a06f5ce	1775735226815	138076	188225

The R language pack shows a 3 minute delay between discovering 4.5.3 and 4.5.2, but I've no idea why:

2026-04-09 13:44:50.889 [info] Registry key HKEY_CURRENT_USER\SOFTWARE\R-core\R64\InstallPath reports the current R installation is at C:\Users\SAW\AppData\Local\Programs\R\R-4.5.3
2026-04-09 13:44:50.889 [info] Identified the current R binary: C:\Users\SAW\AppData\Local\Programs\R\R-4.5.3\bin\x64\R.exe
2026-04-09 13:47:06.517 [info] Possibly found R on PATH: C:\Users\SAW\AppData\Local\Programs\R\R-4.5.2\bin\R.EXE.

R Language Pack Logging.log

This has persisted across multiple PCs, Positron installs, and R versions, more or less since I started using the IDE a few months ago.

[juliasilge]

Thank you so much for these logs! They are super helpful for understanding what is going on. I have logged #12999 for your particular situation.

As a workaround for now, you could set positron.r.interpreters.override to something like this:

{
    "positron.r.interpreters.override": ["C:\\Users\\SAW\\AppData\\Local\\Programs\\R\\R-4.5.3"]   
}

This should stop that problematic which call from ever happening, but it will also turn off discovery for any R binaries you don't explicitly list.

[sawelch-NIVA]

Thanks Julia! I know there are several ongoing issues related to session startup, so I'm not sure if this is the right place, but even with the interpreter override there's still a 2.5 minute delay before R starts:

Positron Runtime Performance Marks

Name	Timestamp	Delta	Total
code/positron/runtimeStartupBegin	1779790515761	0	0
code/positron/runtimeStartupPhase/initializing	1779790515761	0	0
code/positron/runtimeStartupPhase/awaitingTrust	1779790515761	0	0
code/positron/runtimeStartupPhase/starting	1779790524627	8866	8866
code/positron/runtimeStartup/extensionPreActivate/positron.positron-r	1779790524966	339	9205
code/positron/positron.positron-supervisor/initializing	1779790647656	122690	131895
code/positron/positron.positron-supervisor/terminalOpened	1779790647906	250	132145
code/positron/positron.positron-supervisor/started	1779790651678	3772	135917
code/positron/runtimeStartup/extensionPostActivate/positron.positron-r	1779790652000	322	136239
code/positron/positron.positron-supervisor/ready	1779790652606	606	136845
code/positron/runtimeSessionWillStart/r-b5f7ee5a	1779790658912	6306	143151
code/positron/runtimeSessionStart/r-b5f7ee5a	1779790673776	14864	158015
code/positron/firstRuntimeReady	1779790673776	0	158015
code/positron/runtimeStartupPhase/discovering	1779790673823	47	158062
code/positron/runtimeStartupPhase/complete	1779790673863	40	158102

2026.05.28 - positron diag app open then close.txt

2026.05.28 - R output logs.log

As an aside that may or may not prove to be related, I see that I've ended up with ark.exe installed in two locations:
C:\Users\SAW\AppData\Local\Programs\Positron\resources\app\extensions\positron-r\resources\ark
and
C:\Program Files\Positron\resources\app\extensions\positron-r\resources\ark

Is this anything?

[jmcphers]

It's likely you have ark.exe in two places because you've run both the "user setup" and "system setup" versions of the Positron installer at some point in the past. That shouldn't make startup slow, but we'd recommend removing whichever version (user or system) of Positron you don't use, to reduce confusion.

That trace shows a lot of time spent activating extensions; it's hard to tell which since this report focuses only on the extensions directly in the dependency chain for Positron's runtime systems. Could you generate a report from Developer: Startup Performance and attach it?

Finally, are you running any antivirus software? There's a lot of code that gets loaded and read during extension startup and we've seen AV software introduce a lot of startup delays if it's scanning every file that passes through the system.

[victorhartman]

After the latest June update startup times have definitely improved, but it can still take more than a minute to start up. Thought I would share some more diagnostics.

positron_startup_diagnostics_2.txt
positron_startup_diagnostics.txt

[victorhartman]

The above diagnostics are on my corporate laptop with windows defender set to some very strict settings. On my personal pc it's much better at 8495ms.

[juliasilge]

Thank you for the follow-up diagnostics, @victorhartman! These are really useful, and it's great to hear the June update helped.

The good news in your report is that interpreter discovery is no longer the bottleneck. The cache is doing its job, and the "loadingCache" and "discovering" startup phases together take well under 100ms. Your R interpreter is found instantly from the registry.

Almost all of your ~63 seconds is now a single gap. Looking at the performance marks, the R extension pre-activates about 2.3s into startup, but the kernel supervisor doesn't begin initializing until about 55s in. Once it does start, the rest is quick! The supervisor is ready a few seconds later and your R session follows right after.

The supervisor runs in a terminal, so it can't start until the extension host, the pty host, and any terminal startup scripts are all up and running. That ~52s dead zone is the time spent waiting for that to happen, and I believe would be improved by what we're targeting in these issues:

• Startup performance (desktop): Start supervisor concurrently with extension host #12591 (start the supervisor concurrently with the extension host)
• Desktop: Share a supervisor to make Python and R startup faster #6176 (share one supervisor so each window doesn't pay this cost)

A few things in your environment likely make that window slower than usual. This is Windows with the extension host spinning up, the report shows only about 1.67 GB of 15.79 GB free (some memory pressure), and your workspace lives under OneDrive, which can slow down file and terminal operations. If it's easy to try, opening a workspace on a local (non-OneDrive) path is a useful experiment; if that startup is noticeably faster, it would confirm OneDrive is part of the picture here.

We'll keep updating these issues as the supervisor startup work progresses. Thanks again for the detailed reports, as they genuinely help us prioritize.

[victorhartman]

Hi @juliasilge thank you for looking into this in such detail!

After testing for a bit, in general startup now is fast. However after a reboot the first startup can be still quite slow. I have a couple more diagnostics if you want to take a look. I moved my workspace out of onedrive to see if that influences startup times. I do not think it does as I get similar startup times (fast and slow) when using onedrive. And yes low memory does not help, but it is often not possible to close any other processes.

Some context of these diagnostics:
positron_startup_diagnostics_1.txt Here I was working for a while already and just restarted Positron to test startup performance outside of Onedrive. Result: 8654ms. Really good!

These are all after a complete reboot. First startup is slow again, but with each consecutive startup it improves.
positron_startup_diagnostics_2.txt 70847ms
positron_startup_diagnostics_3.txt 48356ms
positron_startup_diagnostics_4.txt 9247ms

Here is another report starting from Onedrive with a fast startup, showing that onedrive probably is not the culprit.
positron_startup_diagnostics_5.txt

[jmcphers]

From the diagnostics:

| code/positron/runtimeStartup/extensionPreActivate/positron.positron-r  | 1780993745439 | 122   | 2888  |
| code/positron/positron.positron-supervisor/initializing                | 1780993805174 | 59735 | 62623 |

It doesn't look like it is slow because of Python or R discovery or startup; those steps are happening pretty quickly. What's taking a long time is getting to the point where we can start extensions in the first place.

The next time you experience a long startup, run the Developer: Startup Performance command and attach it here. I would guess that some other extensions are blocking activation for a while on a cold start.

[sofisinozich]

My startup times have mostly improved since the update, but I'm still seeing delays primarily at the code/positron/positron.positron-supervisor/initializing stage, like others, so wanted to send in my logs in case helpful. This is a corporate Windows laptop. I forgot to run Startup Performance after the first two but am attaching for the third one.

OneDrive folder, after fresh restart (never opened in Positron before):
20260618 - Runtime Startup Diagnostics.txt

Non-OneDrive folder, after fresh restart:
20260618 - Runtime Startup Diagnostics - local.txt

Same OneDrive folder, opened after non-OD folder:
20260618 - Runtime Startup Diagnostics - OD after local.txt
20260618 - Startup Performance - OD after local.txt

Opening the same folder a second time does seem to be a lot faster, but opening different folders is a mixed bag.

[juliasilge]

Thanks for the detailed logs, @sofisinozich! The Startup Performance report you attached is really useful, and IMO it tells a pretty clear story.

In all three of your runs the timeline looks the same: everything is fast except one big gap! Your R extension pre-activates a few seconds in, but the kernel supervisor doesn't begin initializing until ~85-105s later. Almost all of your startup time is that single gap.

The Startup Performance report shows what's filling it. The extension host is single-threaded, and several extensions are spending a very long time just loading their code (a synchronous step that blocks everything queued behind it):

• positron-catalog-explorer: ~42s to load its code
• github: ~15s
• positron-proxy: ~9.5s
• positron-duckdb: ~8.7s
• posit.assistant: ~7.5s
• publisher, markdown, quarto: ~5-6.5s each

Those add up to roughly the length of your gap. A few extensions also do slow async work after loading (copilot-chat ~78s, duckdb ~59s, code-spell-checker ~55s, posit.assistant ~55s, authentication ~44s to finish activating). The supervisor itself is tiny and activates almost instantly once it gets a turn; it's just stuck in line behind all of this.

I think there are two main takeaways here:

1. This is not OneDrive! 😅 Your local run was actually a touch faster than OneDrive in one case and slower in another, so the variance is really about cold-vs-warm extension loading, not the folder location.

2. 42 seconds to load one extension's code is not normal CPU time. That magnitude almost always means antivirus is scanning each file as it's read. On a corporate Windows laptop with strict Defender settings, that fits, and it also explains why the first startup after a reboot is slow but later ones are faster (the files get scanned once, then cached). If your IT policy allows it, adding a Defender exclusion for your Positron install directory and the extensions folder would likely make a big difference. Disabling or uninstalling extensions you don't use day-to-day (for example copilot-chat, code-spell-checker) would also cut the queue down.

On our side, the most relevant work is #12591, which would start the supervisor independently of this end-of-startup extension activation, so it no longer has to wait in that line. That should help your case pretty directly to some level.

Thank you again for the thorough reports!

[mikkmart]

+1 to still experiencing slow startup after 2026.06.0. Here are my diagnostics for a ~2 minute startup: Runtime Startup Diagnostics.txt

[juliasilge]

Thanks for the diagnostics, @mikkmart! Your report looks like the same pattern several other folks in this thread are hitting, and it helpfully rules out a couple of the usual suspects.

Almost all of your ~110s is a single gap. Looking at the performance marks, the R extension pre-activates about 1.3s into startup, but the kernel supervisor doesn't begin initializing until ~96s later:

Name	Delta	Total
code/positron/runtimeStartup/extensionPreActivate/positron.positron-r	64	1322
code/positron/positron.positron-supervisor/initializing	95852	97174

Once the supervisor gets a turn, the rest is quick: it's ready and your R session follows within a few seconds. So the supervisor itself is fine, it's just stuck in line.

The good news in your report:

• This isn't memory (you have 31.46 GB with 13.86 GB free)
• This isn't interpreter discovery (R 4.6.0 is found instantly from the registry, and the discovering phase is trivial)
• This isn't OneDrive (your workspace is a local path)

The supervisor runs in a terminal, so it can't start until the extension host is up. The extension host is single-threaded, and on a cold start (your report shows Initial Startup: true with 133 registered extensions) that ~96s gap is usually other extensions spending a long time just loading their code, with the supervisor queued behind them.

To confirm what's filling the gap, could you do two things?

1. The next time you get a slow startup, run the Developer: Startup Performance command and attach the report here. That will show us which extensions are eating the time.
2. Let us know whether this is a corporate/managed machine with antivirus (e.g. strict Windows Defender settings). Loading code that slowly on a cold start is often antivirus scanning each file as it's read, which also fits the pattern where the first startup after a reboot is slow but later ones are faster.

On our side, the most relevant work is #12591, which would start the supervisor independently of this end-of-startup extension activation so it no longer has to wait in that line. That should help your case fairly directly.

Thanks again for the detailed report!

[mikkmart]

Thanks! Here are both reports for a recent 74 second startup:

Runtime Startup Diagnostics.txt
Startup Performance.txt

Let us know whether this is a corporate/managed machine with antivirus

Yes it is.

[juliasilge]

Thanks for the two reports, @mikkmart! They tell a really clear and consistent story.

Your Runtime Startup Diagnostics show the same shape as several others in this thread: almost all of your ~74s is a single gap. R pre-activates about 1s in, but the kernel supervisor doesn't begin initializing until ~62s later. Once it gets a turn, it's ready and your R session follows within a few seconds. So the supervisor itself is fine, it's just stuck in line.

The Startup Performance report shows what's filling that gap. The extension host is single-threaded, and several extensions spend a long time just loading their code (a synchronous step that blocks everything queued behind it). The standout in your case:

• positron-catalog-explorer: ~36.5s to load its code
• posit.assistant: ~7.4s
• positron-proxy: ~5.3s
• markdown-language-features: ~5.3s
• quarto: ~4.6s
• github, positron-duckdb, copilot-chat, git: ~1-2.5s each

Those add up to roughly the length of your gap, and the supervisor is queued behind all of it.

The thing that stands out is the magnitude: ~36 seconds to load one extension's code is not normal CPU time, especially since that extension then does essentially no work on activation. That pattern, on Initial Startup: true on a corporate Windows machine with strict Defender settings, almost always means antivirus is scanning each file as it's read. It also explains why your first startup after a reboot is slow but later ones are faster (files get scanned once, then cached). If your IT policy allows it, adding a Defender exclusion for your Positron install directory and the extensions folder would probably make the biggest difference.

On our side, the most relevant work is #12591, which would start the supervisor independently of this end-of-startup extension activation so it no longer has to wait in that line. That should help your case fairly directly. Thanks again for the thorough reports, as they help us prioritize this.

I did notice that once again for your case the positron-catalog-explorer is a big contributor and I wonder if there is something we can do to improve that situation. The snowflake-sdk package sitting in node_modules is LARGE, and I wonder if we could somehow avoid it being there to be scanned by Windows Defender in situations where someone doesn't even want to use it. Can we lazy load? Can we prune it?

[juliasilge]

I opened that issue about the Catalog Explorer here: #14446

[arnoudplantinga]

I had the same long start-up times on a corporate laptop, and can confirm that disabling antivirus on the Positron and extensions folders strongly improved start-up time! I used the following Powershell commands:

Add-MpPreference -ExclusionPath "C:\Program Files\Positron\"
Add-MpPreference -ExclusionPath C:\Users\<USERNAME>\.positron\extensions\

[codeswitching]

Hello, OP here. The startup times have improved with each release, but things are still quite slow on my corporate laptop. Here are my diagnostics:

Runtime Startup Diagnostics.txt
Startup Performance.txt

Thank you Julia for helping all of us with these issues, because we really want to use Positron! But it is not a common piece of software in our organization, so IT doesn't know how to support us, and we are left to troubleshoot on our own. If you believe it's a Defender/cybersecurity issue, is there a recommendation of what specific requests I can make to IT?

[jmcphers]

If you're able to use daily builds, we have a number of fixes in them that should further improve your startup time -- if you try them we'd love to hear whether they speed things up for you and if not get an updated startup report.

You might also try:

• disable the Github Copilot extension if you don't use it
• disable the Catalog Explorer extension if you don't use it

as these two extensions load slowly (use @builtin to search for these in the Extensions pane). We have a fix in the dailies that should keep them from loading at all if you aren't using them.

You might ask IT whether it is possible to disable scanning of Positron's app folder and its subfolders (c:\Users\u10543\AppData\Local\Programs\Positron in your case). That's probably a major contributor to your extension load time.

[codeswitching]

I tried the latest daily, it is noticeably faster. Here's the latest:

Runtime Startup Diagnostics.txt
Startup Performance.txt

I do use Github Copilot and would prefer to keep it, and Catalog Explorer is not installed.
I will see if IT can disable scanning, thank you for that suggestion.

Another thing I have noticed for a while - in the terminal at startup, I get this error:

File C:\Users\xxxxx\Documents\WindowsPowerShell\profile.ps1 cannot be loaded because running scripts is disabled on this system. For more information, see 
about_Execution_Policies at https:/go.microsoft.com/fwlink/?LinkID=135170.
At line:1 char:3
+ . 'C:\Users\xxxxx\Documents\WindowsPowerShell\profile.ps1'
+   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : SecurityError: (:) [], PSSecurityException
    + FullyQualifiedErrorId : UnauthorizedAccess

A terminal window is always spawned at some point during startup and immediately closes. It seems like this process has to complete before the interpreter session can load.