diff --git a/src/platforms/javascript/common/troubleshooting/index.mdx b/src/platforms/javascript/common/troubleshooting/index.mdx
index 032eabf5aa96e0..d52e82323ec550 100644
--- a/src/platforms/javascript/common/troubleshooting/index.mdx
+++ b/src/platforms/javascript/common/troubleshooting/index.mdx
@@ -255,6 +255,7 @@ import {
   defaultStackParser,
   defaultIntegrations,
   makeFetchTransport,
+  Hub,
 } from "@sentry/browser";
 
 const client = new BrowserClient({
@@ -264,53 +265,30 @@ const client = new BrowserClient({
   integrations: defaultIntegrations,
 });
 
-client.captureException(new Error("example"));
-```
-
-While the above sample should work perfectly fine, some methods like `configureScope` and `withScope` are missing on the `Client` because the `Hub` takes care of the state management. That's why it may be easier to create a new `Hub` and bind your `Client` to it. The result is the same but you will also get state management with it.
-
-<SignInNote />
-
-```javascript
-import {
-  BrowserClient,
-  defaultStackParser,
-  defaultIntegrations,
-  makeFetchTransport,
-} from "@sentry/browser";
-
-const client = new BrowserClient({
-  dsn: "___PUBLIC_DSN___",
-  transport: makeFetchTransport,
-  stackParser: defaultStackParser,
-  integrations: defaultIntegrations,
-});
-
+// You have to bind the client to a hub, otherwise integrations will not run!
 const hub = new Hub(client);
+// Or, if you already have a hub you want to re-use, you can also do:
+// hub.bindClient(client);
 
-hub.configureScope(function (scope) {
-  scope.setTag("a", "b");
-});
+hub.captureException(new Error("example"));
+```
 
-hub.addBreadcrumb({ message: "crumb 1" });
-hub.captureMessage("test");
+You can now customize the hub to your liking, without affecting other hubs/clients.
 
-try {
-  a = b;
-} catch (e) {
-  hub.captureException(e);
-}
+### Setting up Sentry in shared environments (e.g. Browser Extensions)
 
-hub.withScope(function (scope) {
-  hub.addBreadcrumb({ message: "crumb 2" });
-  hub.captureMessage("test2");
-});
-```
+When setting up Sentry in a shared environment where multiple Sentry instances may run, for example, in a browser extension or similar, you should **not use `Sentry.init()`**, as this will pollute the global state. If your browser extension uses `Sentry.init()`, and the website the extension is running on also uses Sentry, the extension may send events to the website's Sentry project, or vice versa.
+
+For such scenarios, you have to set up a client manually as seen in the example above.
+In addition, you should also avoid adding any integrations that use global state, like `Breadcrumbs` or `TryCatch`.
+As a rule of thumb, it's best to avoid using any integrations and to rely on manual capture of errors only in such scenarios.
 
 ### Dealing with Integrations
 
 Integrations are setup on the `Client`, if you need to deal with multiple clients and hubs you have to make sure to also do the integration handling correctly.
-Here is a working example of how to use multiple clients with multiple hubs running global integrations.
+
+We do not recommend doing this if you are using Sentry in a browser extension or in similar scenarios.
+If you can't avoid using global integrations (e.g. in a micro frontend application), here is a working example of how to use multiple clients with multiple hubs running global integrations.
 
 <SignInNote />