R Freezes When Using `reprex::reprex()`

[danielvartan]

System details:

Positron and OS details:

Positron Version: 2025.08.0 build 130
Code - OSS Version: 1.102.0
Commit: 76ddce5
Date: 2025-08-01T20:12:54.670Z
Electron: 35.6.0
Chromium: 134.0.6998.205
Node.js: 22.15.1
V8: 13.4.114.21-electron.0
OS: Linux x64 6.16.8-arch1-1

Session details:

> sessionInfo()
R version 4.5.1 (2025-06-13)
Platform: x86_64-pc-linux-gnu
Running under: Arch Linux

Matrix products: default
BLAS/LAPACK: /usr/lib/libopenblas.so.0.3;  LAPACK version 3.12.0

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C              
 [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8    
 [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8   
 [7] LC_PAPER=en_US.UTF-8       LC_NAME=C                 
 [9] LC_ADDRESS=C               LC_TELEPHONE=C            
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       

time zone: America/Sao_Paulo
tzcode source: system (glibc)

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods  
[7] base     

other attached packages:
[1] ragg_1.5.0     magrittr_2.0.4

loaded via a namespace (and not attached):
[1] compiler_4.5.1    cli_3.6.5         tools_4.5.1      
[4] textshaping_1.0.3 lifecycle_1.0.4   rlang_1.1.6      
[7] systemfonts_1.2.3

_{Created on 2025-09-25 NOT using reprex v2.1.1}

Describe the issue:

When using reprex, a Tidyverse R package for preparing reprexes for posting to GitHub issues, R becomes unresponsive (freezes).

Steps to reproduce the issue:

1. Open Positron
2. Run reprex::reprex(1 + 1)

Expected or desired behavior:

R should remain responsive; the console should not freeze.

Were there any error messages in the UI, Output panel, or Developer Tools console?

None.

[rodrigosf672]

@danielvartan Thank you for submitting this issue! 🙌

I tested this in the same Positron version you have, but my console is not freezing like yours; I can keep using the console after running reprex::reprex(1 + 1).

@juliasilge or @jmcphers, are you aware of any similar issues in the past? Do you think there is anything else that the user can provide to make it possible to repro the issue?

[juliasilge]

reprex sits on top of some fairly complex infrastructure. I wonder if you would try a few things, @danielvartan:

• Can you use callr as expected, for example with callr::r(function() .libPaths())?
• Can you use rmarkdown to render a local .Rmd file? For example with the Positron command R: Render Document With R Markdown?
• Are you familiar with R debugging? Could you try something like debugonce(reprex:::reprex_render_impl) with a very tiny file such as this one, to identify what is hanging the console:

---
title: "reprex example"
---

Hi!

```{r}
1 + 1
```

You would save this as something like tmp.Rmd and then do reprex:::reprex_render_impl("tmp.Rmd").

[danielvartan]

Hi @juliasilge,

Of course, here are the results.

Can you use callr as expected, for example with callr::r(function() .libPaths())?

Yes. The output is shown below:

[1] "/home/danielvartan/R/x86_64-pc-linux-gnu-library/4.5"
[2] "/usr/lib/R/library" 

Can you use rmarkdown to render a local .Rmd file? For example with the Positron command R: Render Document With R Markdown?

I render Quarto documents regularly without any issues. I also tried R Markdown, and that works fine too.

Are you familiar with R debugging? Could you try something like debugonce(reprex:::reprex_render_impl) with a very tiny file to identify what is hanging the console?

I debugged reprex:::reprex_render_impl while running reprex:::reprex_render_impl("tmp.Rmd") and encountered no problems.

However, when I run reprex::reprex(1 + 1), it gets stuck, and I have to kill the R session.

While debugging reprex::reprex(), I traced the issue to:

Error Track

reprex::reprex(1 + 1)
  |_ reprex:::reprex_impl() 
    |_ reprex:::expose_reprex_output()
      |_ reprex:::reprex_clipboard()
        |_ clipr::clipr_available()
          |_ clipr:::clipr_results_check()
            |_ clipr::write_clip()
              |_ clipr::X11_write_clip()
                |_ clipr::has_wl_copy()
                  |_ clipr::has_util()
                    |_ base::system2()                            

The problem originates from clipr:::has_wl_copy(), which has a bug affecting only Wayland sessions. I explain it here: mdlincoln/clipr#75

I’ve already prepared a PR with the fix: mdlincoln/clipr#76

However, waiting for it may not be practical, since the last clipr update was on February 24, 2022. I suggest considering an alternative solution or creating a fork of the package.

Environment

• Positron Version: 2025.08.0 build 130
• Code - OSS Version: 1.102.0
• Commit: 76ddce5
• Date: 2025-08-01T20:12:54.670Z
• Electron: 35.6.0
• Chromium: 134.0.6998.205
• Node.js: 22.15.1
• V8: 13.4.114.21-electron.0
• OS: Linux x64 6.16.8-arch1-1

[juliasilge]

Thank you so much for digging into this! 🙌 Can you open this as a bug report on the reprex package, at:
https://github.com/tidyverse/reprex/issues

I don't think there is anything for Positron to do differently here, although @jennybc maybe you can chime in if you disagree and see a fix we could make here.

[jennybc]

Yeah there's nothing Positron (or reprex, really) can do about this. As @danielvartan has established, it's a clipr bug.

[juliasilge]

OK, let's look to mdlincoln/clipr#75 for the fix here. If that doesn't happen in a timely manner, maybe reprex will need to think about what to do.

Thanks for the report! 🙌