Laggy behavior likely due to ark bug

[srhrnkn]

I'm getting tons of lags and hangs that sound like they may be related to this bug (which describes the behavior I'm seeing):
#15211

Has anyone found anything to mitigate this while devs are working on the fix?

[Santoshjnawali]

I am experiencing the same. Everything is responding extremely slow and laggy. Posit Assistant takes forever to load and terminates saying UI took too long to respond. Air formatter takes forever. Cannot scroll data explorer.

[juliasilge]

Can you share what version of Positron you are both using? Are you both on the dailies?

[Santoshjnawali]

I was with monthly release until yesterday and things got pretty bad that I am on dailies now and things are still slow and lagging. I feel like Posit Assistant was running smooth until the last two updates (up to version 0.8.0) and it started taking forever to load for first time. My current version of Positron is
Positron Version: 2026.08.0 (user setup) build 213
Code - OSS Version: 1.124.0
Commit: 3dd90db
Date: 2026-07-27T09:59:10-05:00
Electron: 42.2.0
Chromium: 148.0.7778.97
Node.js: 24.15.0
V8: 14.8.178.14-electron.0
OS: Windows_NT x64 10.0.26200

[juliasilge]

The bug outlined in #15211 is only in the dailies, not the monthly release of Positron, so it sounds like that is not the source of the problems you are experiencing.

Two existing issues look like possible matches for what you are experiencing. Both are cases where the R language server or Ark burns CPU, which makes the whole app feel slow even in places that have nothing to do with R (scrolling, the Assistant, and so on):

• Typing lag in long R and Python files: code cells parser reads configuration once per line on every edit #14990
• [Performance] Ark causing high CPU usage (lag, freeze) with large Quarto files #12671

To work out whether that's what's happening here, could each of you share:

1. Your full version details. Help > About, then click Copy, and paste the block here. That gives us the Positron version and build, OS, and architecture in one go.
2. A screenshot of Developer: Open Process Explorer taken while things are laggy. This is the single most useful thing you can send. It shows which process is actually busy: the window itself, the extension host, ark, or the kernel supervisor. Please grab it during the slowness rather than after.
3. Whether it still happens with no R or Python session running. Open a new empty folder, don't start a session, and use the UI for a minute. If it feels fine, the problem is in the language runtime rather than in Positron's UI.

Also helpful, whenever you get a chance:

• Are you using Positron Desktop, Positron in Posit Workbench, or a Remote SSH connection?
• Which language, and what are you doing when it happens? Long R scripts, Quarto documents, notebooks, large data frames sitting in the Variables pane?
• Which version were you on the last time things felt fine, and did the slowness start right after an update (Positron, R, or your OS)?
• Is the project folder on OneDrive, a network share, or a mapped drive, and is corporate antivirus scanning it?
• Does it still happen with extensions disabled? Help: Troubleshoot Issue walks you through this and can tell us whether an extension or a setting is responsible.
• Does Developer: Reload Window help, and if so, for how long?

If Process Explorer shows ark or the R language server near the top, the most useful follow-up is a log. You can set positron.r.trace.server to "messages" and positron.r.kernel.logLevel to "debug", reproduce the slowness, then attach the contents of Output > R Language Server.

[srhrnkn]

Thanks! it's a new day and so far things have been smooth, will try some of the diagnostic suggestions today if the problem shows up again. For now, some partial answers:

1. Is this different than what's pasted above? I don't see an About under Help; do see it under the Positron menu & that's what I pasted above.
2. Will try to grab one today
3. will check

Re bullets:

• using Positron Desktop
• Working on R scripts, not particularly long (one is 300 lines, one 1600 lines - after Air formatting). Largest dataframe loaded was 125K rows x 12 cols
• I did update to 2026.07.1 recently, but not sure what I was on previously
• Project is a local folder
• Will try the last two suggestions today.

[Santoshjnawali]

Thanks for checking these issues! I am using Remote SSH connection and working with R scripts. I have also noticed lag in small sized data frames while scrolling. Posit Assistant sidebar shows black screen without any contents, seems it can't load properly for sometime. This behaviour exists while working locally too. I checked the running extension and Github Copilot Chat (sometime it shows unresponsive), Positron Proxy, and Posit Assistant seems to be requiring most time to activate. I think 2026.06 version was okay but Air formatter issue was still there taking long time. Reloading help for the lags and formatter for sometime but not for the Posit Assistant. Posit Assistant once gets loaded, works fine though.

[juliasilge]

It might be better in the future to have separate discussions for folks in different situations, just as a heads up.

---

@srhrnkn, the version block you pasted is exactly what we needed; thanks!

One detail in your reply is a bigger clue than you may have realized:

when I recreated them as shortcuts in my keybindings.js file they now mostly work

The built-in pipe and assignment shortcuts (r.insertPipe and r.insertLeftAssignment) are handled by an extension, so they have to wait their turn in the extension host. A keybinding that inserts text directly in the editor does not. In another report on the exact same build as yours (#14990) we traced a case where the editor itself stayed perfectly responsive while the extension host was backed up by about 0.7 seconds per keystroke, so an assignment operator took 20 seconds to appear. Your workaround succeeding is precisely what that would predict, which is encouraging.

A few things would help a lot here, roughly in order of usefulness:

1. Could you paste the keybindings you added? If they insert text directly rather than calling the R commands, that is independent confirmation of where the bottleneck is, and it is a workaround other people on this thread can copy today.

2. Something to try that is both a mitigation and the test we most want. My current suspect is Positron's built-in code cells support, which I am suspecting does work on every keystroke that grows with the length of your file. You can turn it off: open the Extensions view, search for @builtin, find Positron Code Cells, click the gear icon and choose Disable, then run Developer: Reload Window.

In a plain R script the only things you lose are Cmd+Shift+I (Insert Code Cell) and the highlight drawn around the current cell. Cmd+Enter and the rest of your shortcuts are unaffected. If your scripts use # %% cell markers and you rely on the Run Cell commands, skip this one. Either way, please tell us what happens, because a "no difference" answer is nearly as useful to us as a "that fixed it".

3. You already have an ideal comparison on disk. You mentioned a 300-line script and a 1600-line one. Is the lag noticeably worse in the 1600-line file? If our suspect is right we would expect something like five times worse.

4. Does it recover? When you stop typing for a second or two, does everything feel normal again, or does it stay slow? This would separate two different bugs for us: a queue that has to drain versus something burning CPU continuously.

5. A 30 second test, if you have a moment. In the 1600-line file, run Change Language Mode and set it to Plain Text, then type quickly. If that is snappy, it tells me the problem is specific to R and Python files.

---

@Santoshjnawali, one clarification on the Running Extensions numbers is that the time shown there is activation time, which is the one-off cost of an extension starting up. That is useful to know, but it will not reveal an extension that is slow on every keystroke afterwards. To capture that, run Developer: Show Running Extensions, click the record button (the filled circle) in the editor's title bar, use Positron for 15 to 20 seconds while it is being slow, then click the stop button. That produces a profile of where the time is actually going, and you can attach the saved .cpuprofile file here.

I also want to flag that your setup looks meaningfully different from the other report in this thread, and I would rather not conflate the two. You are on a daily build (2026.08.0, Code OSS 1.124.0) over Remote SSH, while the other report is a monthly build (2026.07.1, Code OSS 1.118.0) working on local files. More to the point, several of your symptoms are not about typing at all: the black Posit Assistant sidebar, Copilot Chat going unresponsive, and slow scrolling in a small data frame.

The suspect we currently have for the typing and formatting lag only affects R and Python files, so this is the question that would tell us whether you are hitting the same thing:

1. Does the lag also happen in a large plain text or Markdown file? Open a long non-R file over the same connection and type quickly in it. If that is laggy too, then you have a different problem from the other reporter here and we will want to track it separately.

2. Does it recover when you pause? After you stop typing for a second or two, does it feel normal again, or does it stay slow? This distinguishes a backlog that has to drain from something burning CPU continuously.

3. Worth trying, since you work in R scripts. Open the Extensions view, search for @builtin, find Positron Code Cells, click the gear icon and choose Disable, then run Developer: Reload Window. In a plain R script the only things you lose are Ctrl+Shift+I (Insert Code Cell) and the highlight drawn around the current cell. Skip it if your scripts use # %% cell markers and you rely on the Run Cell commands. Please tell us whether it helps, even if the answer is no.

4. Local versus remote. You mentioned this happens while working locally too. Could you confirm whether that was a genuinely local window on a local folder, rather than the same Remote SSH window? Extensions run on the remote machine, so that distinction matters a lot for where we look. If the remote host is shared with other users or is otherwise under load, that is worth knowing as well.

5. The black Posit Assistant sidebar is very likely its own bug, and it will get lost if we track it in here alongside everything else. Would you mind opening a separate issue for it? If you can, run Developer: Toggle Developer Tools while the sidebar is blank and include any red errors from the Console tab.

A Process Explorer screenshot captured while things are actually slow is still the single most useful thing for narrowing this down, so please do grab one if you get the opportunity.

[srhrnkn]

Thanks for maintaining the two conversations - I jumped the gun on diagnosing this, hence the conflation!

Here are the shortcuts. They worked snappily during the lagginess; when I said they "mostly" worked above, it was because I hadn't yet found a typo in one.

{
    "key": "shift+cmd+m",
    "command": "type",
    "args": { "text": " |> " },
    "when": "editorLangId == r" 
  },
  {
    "key": "alt+-",
    "command": "type",
    "args": { "text": " <- " },
    "when": "editorLangId == r" 
  }

Yes, it would recover - once the delayed code execution or autocomplete happened, things would feel normal again until it happened again. There were differences in the lag times but I didn't associate them with the two different files - it's possible that I just didn't notice the pattern, though.

This problem did not occur today, even though I was working in the same project & sometimes on the same files. I had restarted R but not Positron itself. (Some other notes about my usage: I tend to have many Positron folders open at once; and I am using the Github Copilot flavor of the Assistant code completions.)

If it starts again next week I will try the code cell & language mode tests and report back!

[davidjanmassgov]

@srhrnkn @juliasilge - I'm seeing ark take up a lot of memory - around 3gb. Is that related to positron?

Positron Version: 2026.08.1 (user setup) build 2
Code - OSS Version: 1.124.0
Commit: 48dc4ce
Date: 2026-08-09T13:35:16-06:00
Electron: 42.2.0
Chromium: 148.0.7778.97
Node.js: 24.15.0
V8: 14.8.178.14-electron.0
OS: Windows_NT x64 10.0.26200

[juliasilge]

Thank you all for the reports here! We found the cause of the original problem, and the fix is now released. This discussion now holds three separate problems, so I want to clarify.

The typing lag is fixed

@srhrnkn, your problem was not the Ark bug in #15211. That bug was only in the daily builds, and you were on a monthly release.

The cause was #14990: the code cells parser read the configuration one time per line, on every edit. In a long file, this made the extension host slow for every keystroke. The fix for that is #15289, and it is in Positron 2026.08 and later. Please update and tell us if the lag is not gone.

Remote SSH and the blank Assistant sidebar

@Santoshjnawali, your symptoms are a different problem, mostly a blank Posit Assistant, it sounds like. We were also tracking that in #15351, and that is fixed in the latest release of Posit Assistant.

Memory use in ark

@davidjanmassgov, thank you for the screenshots. 3 GB in ark is not necessarily a problem, because ark is the R session itself. Your R objects live inside that process. The positron rows in Task Manager hold the editor, and they do not hold your data. You can compare what R reports with what Windows reports. Run lobstr::mem_used(). If R also reports gigabytes, the memory holds your data and there is no problem, per se (you are just using that much memory in R).

---

This thread is now collecting unrelated reports, I think. If you are observing a problem, it would be most helpful to open a new discussion with your details!