quarto has different `.Rprofile` behavior in Single File mode depending if `--output-dir` is used

[gowerc]

I have:

• searched the issue tracker for similar issues
• installed the latest version of Quarto CLI
• formatted my issue following the Bug Reports guide

Bug description

When using the --execute-dir <dir1> option R will be launched from the target directory <dir1> thus using the .Rprofile of that directory, this is regardless of where the source file lives.

However if you also provide --output-dir <dir2> R will instead be launched from the directory of the source file thus ignoring any .Rprofile file in <dir1> or <dir2>. I'm not 100% sure but I think in this case you are launching R from the source file directory and then internally running setwd() to move the directory to <dir1>. This issue occurs even if <dir1> and <dir2> are the same directory.

Steps to reproduce

> tree -a        
.
├── .Rprofile
├── code
│   └── test2.qmd
└── runme.sh

.Rprofile

cat("hi from code/.Rprofile\n")
cat("getwd() = ", getwd(), "\n")

test2.qmd

---
title: "Untitled"
format: html
---


```{r}
getwd()
```

runeme.sh

quarto render \
  code/test2.qmd \
  --execute-dir $(pwd) \
  --metadata "embed-resources: true"


quarto render \
  code/test2.qmd \
  --output-dir "$(pwd)" \
  --execute-dir "$(pwd)" \
  --metadata "embed-resources: true"

Actual behavior

The first render attempt (just using --execute-dir) makes use of the .Rprofile and produces stdout of:

> quarto render \
  code/test2.qmd \
  --execute-dir $(pwd) \
  --metadata "embed-resources: true"
hi from .Rprofile
getwd() =  /Users/gowercr1/Desktop/Work/xxx-testing-quarto 


processing file: test2.qmd
1/3                  
2/3 [unnamed-chunk-1]
3/3                  
output file: test2.knit.md

The second render however does not load the .Rprofile

> quarto render \
  code/test2.qmd \
  --output-dir "$(pwd)" \
  --execute-dir "$(pwd)" \
  --metadata "embed-resources: true"


processing file: test2.qmd
1/3                  
2/3 [unnamed-chunk-1]
3/3                  
output file: test2.knit.md

Expected behavior

Both should use the .Rprofile from the execution directory

Your environment

MacOS - 26.6.2
R version 4.6.1 (2026-06-24) -- "Happy Hop"

quarto --version
1.10.18

Quarto check output

> quarto check           
Quarto 1.10.18
[✓] Checking environment information...
      Quarto cache location: /Users/gowercr1/Library/Caches/quarto
[✓] Checking versions of quarto binary dependencies...
      Pandoc version 3.10.0: OK
      Dart Sass version 1.101.0: OK
      Deno version 2.7.14: OK
      Typst version 0.15.1: OK
[✓] Checking versions of quarto dependencies......OK
[✓] Checking Quarto installation......OK
      Version: 1.10.18
      Path: /Applications/quarto/bin

[✓] Checking tools....................OK
      TinyTeX: (not installed)
      Chrome Headless Shell: (not installed)
      VeraPDF: (not installed)

[✓] Checking LaTeX....................OK
      Using: Installation From Path
      Path: /Library/TeX/texbin
      Version: 2026

[✓] Checking Chrome Headless....................OK
      Using: Chrome found on system
      Path: /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
      Source: MacOS known location

[✓] Checking basic markdown render....OK

[✓] Checking R installation...........OK
      Version: 4.6.1
      Path: /Library/Frameworks/R.framework/Resources
      LibPaths:
        - /Library/Frameworks/R.framework/Versions/4.6/Resources/library
      knitr: 1.51
      rmarkdown: 2.32

[✓] Checking Knitr engine render......OK

[✓] Checking Python 3 installation....OK
      Version: 3.9.6
      Path: /Library/Developer/CommandLineTools/usr/bin/python3
      Jupyter: (None)

      Jupyter is not available in this Python installation.
      Install with python3 -m pip install jupyter

[✓] Checking Julia installation...

[cderv]

Thanks for the report. I can reproduce, but the mechanism is a bit different from what you described, and the scope is actually wider than this specific flag combination.

--execute-dir never controls where R actually starts, in any configuration. There are two separate "working directory" notions in the R/knitr engine:

• The directory R actually launches in, which is what decides .Rprofile sourcing. This comes from projectDir ?? Deno.cwd(), where projectDir is only set when the render isn't treated as a single file.

quarto-cli/src/execute/rmd.ts

Line 418 in 227676f

const cwd = withinActiveRenv() ? Deno.cwd() : projectDir ?? Deno.cwd();

• knitr's root.dir, which only controls what getwd() reports inside a chunk. This one is wired to --execute-dir.

quarto-cli/src/command/render/render-files.ts

Line 230 in 227676f

cwd: flags.executeDir || dirname(normalizePath(context.target.source)),

So --execute-dir only ever reaches the second one. It never touches the first, which is why .Rprofile behaves the way it does regardless of that flag:

• No project, no --output-dir: this is what we call internally single-file mode, and in this case R starts in whatever directory you ran quarto render from (not --execute-dir).
• No project, --output-dir given: In this case, we internally switch to project mode. --output-dir forces a synthetic project even without a _quarto.yml, and that switches R's start directory to the source file's own directory.

quarto-cli/src/execute/rmd.ts

Line 290 in 227676f

options.project?.isSingleFile ? undefined : options.projectDir,

Your first render only worked because you happened to run the command from the same directory you passed to --execute-dir. It wasn't --execute-dir being honored, it was the shell's cwd matching by coincidence. I confirmed this by running with a distinct .Rprofile in two different directories and swapping which one fires depending only on --output-dir, not on --execute-dir's value. Same result on 1.9.38, so this isn't a regression.

For a real project with a _quarto.yml, R always starts at the project root regardless of --execute-dir, --output-dir, or the shell's cwd. That's probably why this hasn't come up more, project .Rprofile conventionally lives at the project root anyway, so it happens to match. If you use _quarto.yml in your root, it can probably help your case.

There's no clean workaround right now other than sourcing .Rprofile explicitly in the document (as suggested in #10681), or moving it to wherever the render actually starts (project root for a project, or the invocation directory otherwise).

I don't know if current behavior is bad or not. I acknowledge this is surprising behavior due to --output-dir.

--execute-dir controls knitr's root.dir - I am not sure it should also control the actual R process directory.

Related: #10681, #9649

[gowerc]

Thank you for the detailed description !! My use case of quarto so far has been quite narrow but if I got a choice I would vote for starting R from:

• Location of _quarto.yml
• If absent then from the value of --execute-dir
• If unset then from the directory the user launched quarto from

[cderv]

If absent then from the value of --execute-dir

This could be tricky and need to be thought about. --execute-dir is a way to change the working directory for R cells inside documents. root.dir options in knitr and it change the setwd() for R cells after R is opened.
So event in R Markdown and knitr it won't have impact on .Rprofile loading... That is why I am wondering if this is really expected to have --execute-dir be changed.

However, that could make sense in quarto context to have it behave that way. 🤔