diff --git a/03-mocking.Rmd b/03-mocking.Rmd
index d809bda..2e98bb7 100644
--- a/03-mocking.Rmd
+++ b/03-mocking.Rmd
@@ -6,7 +6,7 @@ knitr::opts_chunk$set(
 )
 ```
 
-#  (PART) webmockr details {-}
+# (PART) webmockr details {-}
 
 # Mocking HTTP Requests {#mocking}
 
@@ -79,7 +79,7 @@ webmockr::enable()
 ```
 
 `webmockr` will now by default not allow real HTTP requests from the http 
-libraries that adapters are loaded for (`crul` and `httr`).
+libraries that adapters are loaded for (`crul`, `httr`, `httr2`).
 
 You can optionally allow real requests via `webmockr_allow_net_connect()`, and
 disallow real requests via `webmockr_disable_net_connect()`. You can check 
diff --git a/04-webmockr-stubs.Rmd b/04-webmockr-stubs.Rmd
index 4f01683..f73b3d8 100644
--- a/04-webmockr-stubs.Rmd
+++ b/04-webmockr-stubs.Rmd
@@ -70,7 +70,7 @@ x$get('get', query = list(a = "b"))
 
 
 There are two ways to deal with mocking writing to disk. First, you can create a file
-with the data you'd like in that file, then tell crul or httr where that file is.
+with the data you'd like in that file, then tell crul, httr, or httr2 where that file is.
 Second, you can simply give webmockr a file path (that doesn't exist yet) and some 
 data, and webmockr can take care of putting the data in the file.
 
diff --git a/08-vcr-usage.Rmd b/08-vcr-usage.Rmd
index 713eb8d..1a099fd 100644
--- a/08-vcr-usage.Rmd
+++ b/08-vcr-usage.Rmd
@@ -49,6 +49,10 @@ out$parse()
 This also works with `httr`. The only difference is that you write to disk
 with a function `httr::write_disk(path)` rather than a parameter.
 
+::: {.alert .alert-dismissible .alert-info}
+Writing to disk with `{httr2}` does not yet work with `{vcr}` - see <https://github.com/ropensci/vcr/issues/270>
+:::
+
 Note that when you write to disk when using `vcr`, the cassette is slightly
 changed. Instead of holding the http response body itself, the cassette
 has the file path with the response body.
diff --git a/Makefile b/Makefile
index 8d26e7f..dadb85c 100644
--- a/Makefile
+++ b/Makefile
@@ -2,4 +2,4 @@ render:
 	Rscript -e "bookdown::render_book('index.Rmd')"
 
 serve:
-	Rscript -e "bookdown::serve_book()"
+	Rscript -e "bookdown::serve_book(in_session = FALSE)"
diff --git a/_common.R b/_common.R
index 2937786..64dbd13 100644
--- a/_common.R
+++ b/_common.R
@@ -1,6 +1,7 @@
 dir.create("rmd-fragments")
 
 get_vcr_doc <- function(path) {
+  webmockr::disable()
   fs::dir_create(dirname(file.path("rmd-fragments", path)), recurse = TRUE)
   fragment_api <- gh::gh(
     "/repos/:owner/:repo/contents/:path",
@@ -13,4 +14,4 @@ get_vcr_doc <- function(path) {
     file = file.path("rmd-fragments", path)
     )
 }
-options(knitr.duplicate.label = "allow")
\ No newline at end of file
+options(knitr.duplicate.label = "allow")
diff --git a/intro-pkgs.Rmd b/intro-pkgs.Rmd
index 7b6e8a7..44ba2d7 100644
--- a/intro-pkgs.Rmd
+++ b/intro-pkgs.Rmd
@@ -31,7 +31,7 @@ What are the challenges of HTTP testing?
 * While `{webmockr}` is in use, real HTTP interactions are not allowed. Therefore you need to stub all possible HTTP requests happening via your code. You'll get error messages for HTTP requests not covered by any stub.
 * There is no recording interactions to disk at all, just mocked responses given as the user specifies in the R session.
 
-`{webmockr}` works with both the `{crul}` package and the `{httr}` package.
+`{webmockr}` works with `{crul}`, `{httr}`, and `{httr2}`.
 
 `{webmockr}` is quite low-level and not the first tool you'll use directly in your day-to-day HTTP testing.
 You may never use it directly but if you use `{vcr}` it's one of its foundations.
@@ -49,7 +49,7 @@ Therefore tests work independently of an internet connection.
 
 `{vcr}` was inspired by the [Ruby vcr gem](https://relishapp.com/vcr/vcr/docs).
 
-`{vcr}` works for packages using `{httr}` or `{crul}`.
+`{vcr}` works for packages using `{httr}`, `{httr2}` or `{crul}`.
 
 ::: {.alert .alert-dismissible .alert-info} 
 [Direct link to `{vcr}` (& `{webmockr}`) demo](#vcr)
@@ -99,7 +99,7 @@ Because it runs a fake web service, you can even interact with said web service
 [Direct link to `{webfakes}` demo](#webfakes)
 :::
 
-## testthat 
+## testthat
 
 `{testthat}`, maintained by Hadley Wickham, is not a package specifically for HTTP testing; it is a package for general-purpose unit testing of R packages.
 In this book we will assume that is what you use, because of its popularity.
diff --git a/wholegames-comparison.Rmd b/wholegames-comparison.Rmd
index 201eb6b..ad94978 100644
--- a/wholegames-comparison.Rmd
+++ b/wholegames-comparison.Rmd
@@ -7,10 +7,10 @@ Of course, the choice of strategy in the demo is a bit subjective, but we hope i
 A first message that's important to us: if you're learning about HTTP testing and using it in a branch of your own package sounds daunting, create a minimal package for playing!
 :::
 
-## What HTTP client can you use (curl, httr, crul)
+## What HTTP client can you use (curl, httr, httr2, crul)
 
 * httptest only works with httr (the most popular HTTP R client);
-* vcr (& webmockr) works with both httr and crul (the two "high-level" HTTP R clients);
+* vcr (& webmockr) works with httr, httr2, and crul (the three "high-level" HTTP R clients);
 * webfakes works with any R HTTP client, even base R if you wish.
 
 ## Sustainability of the packages