Error Starting R after updating to 2026.07.0-139

bastimapache · July 10, 2026, 2:53pm

Just updated to RStudio 2026.07.0-139, and got a "Error Starting R" screen.

Downgraded to 2026.06.0-242 and still got the same error, then downgraded to 2026.05.2-229 and at last RStudio launched properly. It seems to be related to folder permissions, but this wasn't an issue before. Also the message mentions something about Claude, so I tried commenting out my ~/.Rprofile, but error persisted.

Error report added below:

R Session Startup Failure Report

RStudio Version

RStudio 2026.07.0+139 "Pacific Dogwood " (5c876ced, 2026-07-09) for macOS

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) RStudio/2026.07.0+139 Chrome/146.0.7680.216 Electron/41.9.0 Safari/537.36

Error message

The R session had a fatal error.

2026-07-10T14:46:48.132963Z [rsession-bolea] ERROR system error 13 (Permission denied) [path: /Users/bolea/.local/share/rstudio/monitored/lists/6f07-a971-bed1-6b42, target-path: /Users/bolea/.local/share/rstudio/monitored/lists/project_name_mru]; OCCURRED AT Error rstudio::core::FilePath::move(const FilePath &, MoveType, bool) const src/cpp/shared_core/FilePath.cpp:1578

Process Output

The R session exited with code 2.

Error output:

2026-07-10T14:46:48.132963Z [rsession-bolea] ERROR system error 13 (Permission denied) [path: /Users/bolea/.local/share/rstudio/monitored/lists/6f07-a971-bed1-6b42, target-path: /Users/bolea/.local/share/rstudio/monitored/lists/project_name_mru]; OCCURRED AT Error rstudio::core::FilePath::move(const FilePath &, MoveType, bool) const src/cpp/shared_core/FilePath.cpp:1578

Standard output:

[No output emitted]

Logs

/Users/bolea/.local/share/rstudio/log/rsession-bolea.log

2026-05-06T20:13:09.189134Z [rsession-bolea] WARNING [onBackendStderr]: Chat backend stderr: AI SDK Warning (anthropic.messages / claude-sonnet-4-6): unsupported reasoning metadata; LOGGED FROM: void rstudio::session::modules::chat::(anonymous namespace)::onBackendStderr(core::system::ProcessOperations &, const std::string &) src/cpp/session/modules/SessionChat.cpp:4438
2026-06-05T20:14:35.701637Z [rsession-bolea] WARNING [onBackendStderr]: Chat backend stderr: AI SDK Warning: System messages in the prompt or messages fields can be a security risk because they may enable prompt injection attacks. Use the system option instead when possible. Set allowSystemInMessages to true to suppress this warning, or false to throw an error.; LOGGED FROM: void rstudio::session::modules::chat::(anonymous namespace)::onBackendStderr(core::system::ProcessOperations &, const std::string &) src/cpp/session/modules/SessionChat.cpp:4608
2026-07-06T13:49:59.767071Z [rsession-bolea] ERROR CLIENT EXCEPTION (rsession-bolea): (TypeError) : Cannot read properties of null (reading 'document');|||org/rstudio/core/client/dom/WindowEx.java#151::getDocument|||org/rstudio/core/client/widget/DynamicIFrame.java#106::getDocument|||org/rstudio/studio/client/workbench/views/source/editors/text/ChunkOutputFrame.java#106::run|||com/google/gwt/user/client/Timer.java#124::fire|||rstudio-0.js#-1::anonymous|||com/google/gwt/core/client/impl/Impl.java#296::apply|||com/google/gwt/core/client/impl/Impl.java#335::entry0|||rstudio-0.js#-1::anonymous|||Client-ID: 33e600bb-c1b1-46bf-b562-ab5cba070b0e|||User-Agent: Mozilla/5.0 (Macintosh  Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) RStudio/2026.05.0+218 Chrome/146.0.7680.216 Electron/41.5.0 Safari/537.36

bastimapache · August 5, 2026, 4:44pm

Solved: fatal error at session startup caused by deny delete ACLs on ~/.local/share/rstudio

(Disclaimer: I used Claude Code to find this solution by explaining the situation and pasting the error message, which worked, but it also surfaced some issues that could be fixed in RStudio itself)

Following up on my own report with the root cause and the fix, in case it helps someone searching for this error — and in case it's useful to the RStudio developers, because I think the failure mode is worth handling more gracefully.

Environment

RStudio 2026.07.1+147 "Pacific Dogwood" (49299327) for macOS, installed in ~/Applications (no admin privileges on this machine)
macOS 14 (Darwin 23.6.0), Intel
Active Directory / network user account, non-admin
R 4.6.1 installed via Homebrew (/usr/local/bin/R)

Symptom

Every session died immediately at startup with "The R session had a fatal error", and rsession-bolea.log showed:

ERROR system error 13 (Permission denied)
  [path: /Users/bolea/.local/share/rstudio/monitored/lists/b811-5f02-4098-6d09,
   target-path: /Users/bolea/.local/share/rstudio/monitored/lists/project_name_mru];
OCCURRED AT Error rstudio::core::FilePath::move(const FilePath &, MoveType, bool) const
  src/cpp/shared_core/FilePath.cpp:1578

Root cause

Everything under ~/.local/share/rstudio was rw- for my own user, and RStudio had been writing there fine for over a year. The problem is a macOS ACL. At my workplace, IT applies these entries recursively across the user home:

$ ls -le ~/.local/share/rstudio/monitored/lists/project_name_mru
-rw-r-----@ 1 bolea  DOMAIN\Domain Users  1177 Aug  5 10:46 project_name_mru
 0: group:everyone deny delete
 1: user:someadmin allow read,readattr,readextattr,readsecurity

My account is a member of everyone, so the deny delete entry applies to me on my own files.

RStudio writes these state files atomically: it writes a temporary file with a random name and then rename()s it over the final name (hence FilePath::move with b811-5f02-4098-6d09 as source and project_name_mru as target). On macOS, replacing an existing destination via rename() requires delete permission on that destination, and the deny delete ACE blocks exactly that. Result: EPERM, and the session aborts during initialization.

Minimal reproduction, no RStudio involved:

$ cd /tmp && mkdir acltest && cd acltest
$ echo old > destination; echo new > temporary
$ chmod +a "group:everyone deny delete" destination
$ mv temporary destination
mv: rename temporary to destination: Permission denied

$ chmod -a "group:everyone deny delete" destination
$ mv temporary destination        # succeeds

Worth noting why this surfaced only now: the ACLs are not new — my log has a benign Permission denied on FilePath::remove() for ~/.local/share/rstudio/sources/per/t going back to July 2025. Earlier RStudio versions evidently did not depend on a successful replace-by-rename in this code path at startup, so the same ACLs were harmless. Whatever changed, the write is now on the fatal path.

Fix

Remove just the offending ACE from RStudio's state directories, leaving the rest of the ACL intact:

find ~/.local/share/rstudio ~/.config/rstudio \( -type f -o -type d \) -print0 \
  | xargs -0 -I{} chmod -a "group:everyone deny delete" "{}"

Two gotchas:

Use xargs -I{} (one path per chmod invocation). If you pass many paths at once, chmod aborts the remainder of the batch as soon as it hits a file with no ACL at all (chmod: No ACL present ...), silently leaving most files untouched. My first pass only cleared 99 of 285 entries because of this.
Do not strip the ACL from ~, ~/.local or ~/.local/share themselves. group:everyone deny delete on the home directory and on the standard top-level folders is a macOS default that protects those folders from being deleted; it does no harm because nothing renames over those directories.

Verification, in order of usefulness:

# 1. no deny-delete ACEs left under RStudio's state dirs
find ~/.local/share/rstudio ~/.config/rstudio \( -type f -o -type d \) \
  | while read -r p; do ls -lde "$p" | grep -q "deny delete" && echo "$p"; done | wc -l   # → 0

# 2. the exact operation rsession performs now succeeds
cd ~/.local/share/rstudio/monitored/lists
echo test > .tmp1 && mv .tmp1 target && echo test > .tmp2 && mv .tmp2 target && rm target

# 3. newly created files do NOT inherit the ACE, so the fix is durable
cd ~/.local/share/rstudio/monitored/lists && echo x > .newfile && ls -le .newfile && rm .newfile

In step 3, the ACEs in my case were applied recursively by a one-off IT action, not through file_inherit/directory_inherit flags on a parent directory, so they don't come back on newly created files. If your parent directories do carry inheritance flags (ls -lde will show inherited / file_inherit), or if an MDM policy re-applies the ACLs on a schedule, cleaning the files is only a temporary fix and you'll need the inheriting ACE on the parent removed, or an exclusion for ~/.local and ~/.config, by whoever manages the machine.

Also check your project directories — in my case ~/Documents/**/.Rproj.user was clean, but the same failure mode would apply there (source database, session state) if it weren't.

A few things that would have saved me a couple of hours here, if any of this is useful:

A failed atomic write of an MRU list probably shouldn't be fatal. monitored/lists/* holds most-recently-used entries and the user dictionary — non-essential state. If the replace-by-rename fails with EPERM/EACCES, degrading to a logged warning (and starting the session with an empty/stale MRU) would be much better than aborting startup. As it stands, unwritable convenience state takes down the whole IDE.
Consider a fallback path when rename() fails with EPERM/EACCES. Truncate-and-rewrite in place works fine under this ACL (the file is writable; only deleting it is denied). A fallback would make RStudio work out of the box on managed macOS fleets, where everyone deny delete on user data is a common hardening pattern. Enterprise-managed, AD-bound, non-admin macOS accounts are likely a non-trivial share of the install base.
Surface the ACL in the diagnostic. The log correctly reports EPERM with both paths, but on macOS EPERM from rename() with mode bits that clearly permit the operation is almost always an ACL. Appending the destination's ACL (or just a hint: "the destination may carry a deny delete ACL; check ls -le") would point users at the cause immediately, instead of at the file permissions they can already see are fine.