Qualify Context Bridge on Ubuntu

Build and test the Context Bridge Firefox extension on Ubuntu.

Introduction

30 Second Summary

A project can look finished on one computer yet stumble as soon as it moves to another. Small differences in installed software or file access can stop the whole workflow.

In this project, you will qualify the existing Context Bridge browser extension on Ubuntu. You will produce a written baseline that shows whether its full local workflow is ready for later provider work.

What You'll Build

At the finish line, you can show the full Context Bridge sidebar running beside NextWork in Firefox as a local file becomes a queued chunk ready for handoff.

By the end of this project, you'll have:

A repeatable Ubuntu build that you can restore from package-lock.json without changing the inherited dependency choices.
An expanded sidebar that accepts a text file, a nested folder, or a ZIP archive before showing a readable chunk queue.
A written qualification baseline that gives the Ubuntu migration a clear go or no-go result backed by recorded evidence.
Secret Mission: Recover the full Context Bridge workflow after a cold Firefox restart.

Are there any prerequisites?

You need Ubuntu 24.04 LTS on x64 plus the complete Context Bridge source folder containing package-lock.json.

Firefox, NextWork, Visual Studio Code, and internet access should already be available.

Before We Start

Before any hands-on work, you'll commit to qualifying the implementation that actually exists in the Context Bridge source folder. This keeps later changes to providers, models, or permissions grounded in a proven Ubuntu baseline.

Expose the Ubuntu Blockers

You have already defined what a trustworthy Ubuntu qualification must prove. Now you need to inspect the inherited project exactly as it arrived.

The missing runtime blocks every build attempt. Firefox Snap confinement can also block access to source stored outside your home directory.

In this step, get ready to:

Open the inherited source as a Visual Studio Code workspace.
Expose the Node.js runtime result plus the Firefox package source.
Create a qualification report containing the initial findings.

Open the inherited workspace

A Visual Studio Code workspace gives the source files plus the terminal one shared location. Opening the inherited folder first keeps every check tied to the implementation you are qualifying.

Press the Super key to open Ubuntu's app search.
Type Visual Studio Code in the search field.
Press Enter to open Visual Studio Code.
Click File in the top menu.
Select Open Folder.
Select the existing Context Bridge source folder.
Click Open.

You will see the inherited source fill the Explorer sidebar.

Confirm that package.json appears in the Explorer sidebar.
Confirm that package-lock.json appears in the Explorer sidebar.
Click View in the top menu.
Select Terminal.

The integrated terminal starts at the workspace root. This is the same folder that contains both package files.

Why do both package files matter?

The package.json file describes the project. The package-lock.json file preserves its inherited dependency decisions.

Confirming both files now protects the qualification from starting with an incomplete source folder.

Reveal the missing runtime

The source needs a JavaScript runtime plus its package manager before any build can start. These first checks expose the current machine state without changing it.

Before you run these checks, do you expect Ubuntu to recognize either command?

Check the runtime plus package manager availability by running these commands:

node --version
npm --version

What do these checks prove?

The node check asks the shell whether the JavaScript runtime is available.
The npm check asks whether its package manager is available.

Your terminal reports that Node.js is unavailable. The npm check also fails because the package manager is unavailable.

That failure is the intended blocker. You now have evidence that the build cannot start on the current machine.

Firefox packaging creates the second qualification condition. The installed Snap list reveals whether Snap confinement applies to this workflow.

Before you check, do you think Firefox will appear in Ubuntu's Snap list?

Identify the installed Snap packages by running this command:

snap list

What does this command show?

The command lists packages installed through Snap. A firefox row confirms that Firefox is Snap-packaged.

You will either see a firefox row or confirm that Firefox came from another package source.

Seeing a different result?

Record the exact version if the node check unexpectedly succeeds. Leave the installation unchanged in this step.
Record Firefox as coming from another package source if the Snap list contains no firefox row.

Get help interpreting the checks before changing anything: Help me interpret my Ubuntu runtime and Firefox package results.

Protect access to the source

A Snap-packaged Firefox can have trouble reading extension files from an external or non-native mount. The source location therefore becomes part of the qualification result.

Press the Super key to open Ubuntu's app search.
Type Files in the search field.
Press Enter to open Ubuntu Files.
Locate the Context Bridge source folder that is open in Visual Studio Code.
Read the folder location shown in Ubuntu Files to determine whether it sits inside Home.

✔️ The source location is ready

The current workspace is ready if Firefox is not a Snap or the source already sits inside your home directory.

Keep the current Context Bridge folder open in Visual Studio Code.

ⓧ Move the source under Home

Firefox is Snap-packaged while the source sits on an external or non-native mount. A complete copy under your home directory gives Firefox a safer development path to the build files.

Select the complete Context Bridge folder in Ubuntu Files.
Use Ubuntu Files to copy the selected folder.
Select Home in the Ubuntu Files sidebar.
Use Ubuntu Files to paste the complete folder into Home.

Good work. The complete working copy is now under your home directory where Firefox can reach it.

Return to Visual Studio Code.
Click File in the top menu.
Select Open Folder.
Double-click the copied Context Bridge folder under Home.

Return to Visual Studio Code from earlier.
Click the trash can in the terminal toolbar to end the current shell.
Click View in the top menu.
Select Terminal.
Confirm that package.json remains visible in the Explorer sidebar.
Confirm that package-lock.json remains visible in the Explorer sidebar.

The fresh terminal now starts at the workspace root for the working Context Bridge copy.

The qualification report turns environment state into evidence. Record the observations without fixing the blockers yet.

Select the new-file control in the Explorer sidebar.
Enter ubuntu-qualification.md as the file name.
Record that the initial Node.js check reported the runtime as unavailable.
Record that the initial npm check reported the package manager as unavailable.

Your report now captures the first qualification result. The inherited source cannot build with the current runtime state.

Record whether the Snap list contained a firefox row.
Record whether the working Context Bridge folder is under your Ubuntu home directory.
Save ubuntu-qualification.md.

Before you review the report, do you expect it to show a missing runtime plus a clear Firefox package result?

Review ubuntu-qualification.md from top to bottom.

You will see the Node.js result plus the npm result recorded in the report. You will also see the Firefox package result plus the working folder location.

Your Ubuntu baseline is documented before any installation changes the machine. Next, you will restore the locked build environment from this known starting point.

Restore the Locked Build Environment

The inherited Context Bridge source cannot build on Ubuntu while its Node.js runtime is missing. WXT 0.21.4 requires Node 22 or newer.

A per-user nvm installation provides the required runtime without replacing Ubuntu's system packages. Reproducible dependency restoration then rebuilds the inherited dependency tree from its lockfile.

In this step, get ready to:

Install curl and nvm 0.40.8.
Activate Node.js v24.22.2 with npm 11.19.1.
Restore the locked dependencies and confirm the Firefox build script is available.

Install curl and nvm

The curl command downloads the official nvm installer. Ubuntu's package index needs a refresh before the system can install curl.

Ubuntu may request your account password before changing system packages. Hidden password typing in the terminal is normal.

Refresh Ubuntu's local package index by running this command:

sudo apt update

What does this command do?

This refreshes Ubuntu's local list of available packages. It gives the installer current package information before curl is installed.

The terminal returns to its prompt after the package index refresh completes.

The installer may request confirmation before it downloads curl.

Install curl from Ubuntu's package repositories by running this command:

sudo apt install curl

What does this command do?

This installs the verified curl package from Ubuntu's repositories. Curl provides the download command used by nvm's official installer.

The terminal returns to its prompt after curl finishes installing.

The nvm installer places the version manager in your home directory. Its version is fixed by the installer URL.

Install nvm 0.40.8 by running its official installation command:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.8/install.sh | bash

How does this installer work?

The first part downloads the nvm 0.40.8 installation script from its official repository.
The pipe passes that script to Bash for installation in your home directory.
The installer updates your shell configuration so new terminal sessions can find nvm.

The installer reports its setup work before returning control to the terminal.

Did the installation stop?

Check that Ubuntu still has internet access. Confirm that the package-index command completed before retrying the failed installation command.

If the failure continues, help me diagnose why curl or the nvm installer failed on Ubuntu. The NextWork community can also help with machine-specific installation issues.

Activate the required Node.js toolchain

The current shell started before nvm changed your shell configuration. A fresh terminal session loads that configuration.

Close the current integrated terminal session with the trash can icon in the terminal panel.
Press Ctrl+` to reopen the Visual Studio Code terminal at the workspace root.
Confirm the reopened terminal can find nvm by running this command:

command -v nvm

What does this check prove?

This asks the shell to locate the nvm command. A result confirms that the reopened terminal loaded the updated shell configuration.

The terminal prints nvm when the version manager is available.

Install the current Node.js 24 release by running this command:

nvm install 24

What does this command do?

Nvm downloads the current release on the Node.js 24 line. It also activates that runtime for the reopened terminal.

Before you check, picture the two version numbers you expect the terminal to print.

Check the active Node.js and npm versions by running these commands:

node -v
npm -v

What do these checks show?

The first command prints the active Node.js version.
The second command prints the npm version bundled with that Node.js release.

✔️ I see the required versions

The runtime gate is cleared. Node.js v24.22.2 is active with npm 11.19.1.

Continue to the dependency restoration substep.

ⓧ I see older versions

The reopened terminal is using an older Node.js installation. Nvm can activate the required release for this workspace session.

Install the required release and repeat both version checks by running these commands:

nvm install 24
node -v
npm -v

What happens here?

The first command installs and activates the current Node.js 24 release. The remaining commands print the active Node.js and npm versions.

Continue when the terminal shows Node.js v24.22.2 followed by npm 11.19.1.

ⓧ Command not found

The shell has not activated a Node.js runtime through nvm.

Close the current integrated terminal session with the trash can icon in the terminal panel.
Press Ctrl+` to open a fresh terminal session.
Install the required release and repeat both version checks by running these commands:

nvm install 24
node -v
npm -v

Why retry in a fresh terminal?

A fresh shell loads nvm's configuration before the runtime installation begins. The version checks then confirm which runtime that shell activated.

Continue when the terminal shows Node.js v24.22.2 followed by npm 11.19.1.

Still seeing the wrong runtime?

Confirm that the nvm location check prints nvm in the same terminal where you run the version checks. Close that terminal session once more if the location check is blank.

If the versions still do not match, help me find why my reopened Ubuntu terminal is not using Node.js v24.22.2 from nvm. The NextWork community can help compare shell-specific results.

Restore and verify the locked dependencies

The existing package-lock.json records the dependency decisions inherited with Context Bridge. A clean restore recreates node_modules from that record.

Why use the lockfile?

A clean lockfile restore removes any existing dependency folder before installation. It stops if the package manifest disagrees with the lockfile.

A successful restore leaves the package manifest and lockfile unchanged. That preserves the baseline you are qualifying.

A clean dependency restore can take a few minutes while npm downloads the locked packages. Continuous terminal output means the installation is still working.

Restore the inherited dependency tree from the lockfile by running this command:

npm ci

What does this command do?

It requires the existing lockfile before installation can begin.
It removes an existing node_modules folder before restoring packages.
It exits when the package manifest and lockfile disagree.
It does not rewrite either dependency file.

A successful restore finishes without an installation failure. The terminal then returns to its prompt.

Did the clean restore fail?

Treat a lockfile mismatch as qualification evidence.
Treat an unsupported engine result as qualification evidence.
Leave the inherited lockfile unchanged.
Leave all package versions unchanged.
Record the outcome as a red qualification result in ubuntu-qualification.md.

For help preserving the evidence, help me interpret my clean dependency restore failure without changing package versions or rewriting package-lock.json. The NextWork community can help review the non-secret terminal output.

Before the final check, picture the runtime signals and project script you expect to see.

Verify the complete toolchain and list the project scripts by running these commands:

command -v nvm
node -v
npm -v
npm run

What does the final check prove?

The first command proves nvm is available in the reopened shell.
The next two commands identify the active Node.js and npm versions.
The final command reads the scripts declared by the inherited project.

The first command prints nvm. The next command prints v24.22.2.

The npm version check prints 11.19.1. The script list includes build:firefox.

You have cleared the locked-environment gate. Context Bridge now has a reproducible Ubuntu toolchain and its inherited dependency tree.

What to capture in the report

The successful curl installation.
The nvm version 0.40.8.
The active Node.js version v24.22.2.
The active npm version 11.19.1.
The clean dependency restore result.
The presence of the build:firefox script.

Update ubuntu-qualification.md in its existing editor tab with every result from the checklist above.
Save ubuntu-qualification.md.

The saved report now records whether the inherited project passed its Ubuntu toolchain gate. Any lockfile or engine failure remains visible as a red result.

Your locked build environment is restored and documented. Next, you will produce the Firefox build and put the expanded Context Bridge sidebar on screen.

Build and Load the Firefox Extension

Your locked dependencies are restored inside VS Code. The inherited source still needs a browser-ready build before Firefox can execute it.

On Ubuntu, Firefox may run inside Snap confinement. Loading the generated manifest manually bypasses the Snap-sensitive automatic launcher used by WXT.

In this step, you will create the production Firefox MV2 build. You will load it into your current Firefox profile to prove that the complete sidebar reaches the browser.

In this step, get ready to:

Build the production Firefox MV2 target.
Load the generated manifest as a temporary add-on.
Confirm the expanded sidebar beside NextWork.

Build the production Firefox target

The Firefox MV2 target packages the inherited source into files that Firefox can load. A successful build closes the gap between restored dependencies and a runnable browser extension.

Before you run the build, do you expect the restored dependency tree to produce the Firefox target cleanly?

Create the production Firefox build by running this command:

npm run build:firefox

What does this command do?

The build:firefox package script selects the inherited Firefox production target.
WXT writes the generated extension files to .output/firefox-mv2.
The generated .output/firefox-mv2/manifest.json file describes the temporary add-on that Firefox loads.

Wait for the VS Code terminal prompt to return.
Confirm that the build output contains no build errors.
Expand .output in the VS Code Explorer sidebar.
Confirm that .output/firefox-mv2 exists.
Confirm that .output/firefox-mv2/manifest.json exists.

That clears the build barrier. Your inherited source now has a production Firefox MV2 target that the browser can load.

Build not completing?

Confirm that the terminal is still at the Context Bridge workspace root.
Confirm that the earlier locked dependency restoration completed successfully.
Keep the inherited package versions unchanged while you investigate the build output.
Record the build failure as a red qualification result in ubuntu-qualification.md.

Use the build output to narrow down the failure before changing the locked dependency tree. Help me diagnose this Firefox build failure without changing package versions or rewriting the lockfile.

Load the manifest into Firefox

Manual temporary loading sends the completed build directly to Firefox's development interface. This keeps the qualification test inside your current browser profile.

Why load the manifest manually?

WXT's automatic Firefox launcher can fail when Firefox is Snap-packaged. Manual loading avoids that launcher while preserving the production build you just created.

Press the Windows key to open Ubuntu's application search.
Type Firefox into the search field.
Press Enter to launch Firefox.
Load about:debugging from the Firefox address bar.
Select This Firefox.
Click Load Temporary Add-on.
Select .output/firefox-mv2/manifest.json from the Context Bridge workspace.

Firefox returns to the development page with Context Bridge listed as a temporary extension. You have now moved the production build into your current Firefox profile.

Firefox cannot load the manifest?

Confirm that you selected the generated .output/firefox-mv2/manifest.json file.
Check ubuntu-qualification.md for the recorded Firefox package type.
Confirm that the active workspace is under your Ubuntu home directory when Firefox is Snap-packaged.
Use Ubuntu Files to copy the complete Context Bridge folder into your home directory when the active copy is on an external or non-native mount.

Use the copied workspace as the active source before you retry the temporary load.

Switch back to VS Code.
Click File in the top menu bar.
Click Open Folder.
Select the copied Context Bridge folder.
Click Open.
Rebuild the Firefox target using the build command from the previous substep.
Repeat the temporary manifest load from the copied workspace.

Use these checks to separate a generated-path problem from a Snap access problem. Help me check why Firefox cannot load my generated Context Bridge manifest.

Check the expanded sidebar

The temporary extension listing proves that Firefox accepted the manifest. The product check happens when the complete sidebar opens beside a real NextWork project.

Open NextWork in Firefox.
Open one of your existing NextWork projects.

Before you open Context Bridge, do you expect the inherited implementation to show the complete expanded card set?

Open Context Bridge from Firefox's extension controls.
Inspect the sidebar from top to bottom.

You should see the complete expanded Context Bridge card set beside the open NextWork project. This proves that the Ubuntu build reaches the browser as a usable sidebar.

What should the report capture?

Build result: the Firefox production target completed without build errors.
Temporary load result: Firefox accepted the generated manifest.
Sidebar result: the complete expanded card set appeared beside NextWork.

Switch back to ubuntu-qualification.md in VS Code.
Add one result summary covering the build result, temporary add-on load, and expanded card-set observation.
Save ubuntu-qualification.md.

You have crossed the build-to-product gap. Context Bridge now runs beside NextWork as a temporary extension in your current Firefox profile.

Your Firefox build is live in the browser. Next, you will test the local pipeline from source input through the NextWork handoff.

Test the Local Pipeline

Your production build is running in Firefox. The expanded Context Bridge sidebar is ready for a real flight test.

A visible sidebar only proves that the interface renders. Linux paths or ZIP archive handling can still break the local pipeline.

Local queue generation needs direct evidence. The first chunk must also reach NextWork through the handoff path.

In this step, get ready to:

Prepare a harmless local test set.
Generate a queue with an implemented local-only skill.
Complete a NextWork handoff and record the qualification results.

Prepare the harmless test set

The test set needs distinct source shapes so each input path has something concrete to process. Short fictional sentences keep the flight test free from personal or sensitive data.

Switch back to VS Code from earlier.
Select the file sidebar.
Use the new-folder control to create qualification-test-set inside the open Context Bridge workspace.

You should see qualification-test-set beneath the workspace folder.

Select qualification-test-set.
Use the new-file control to create single-note.txt.

You should see single-note.txt inside the test-set folder.

Enter Ubuntu qualification root file. in single-note.txt.
Save single-note.txt.

The saved file should contain one readable sentence.

Use the new-folder control to create nested-notes inside qualification-test-set.

You should see an empty nested-notes folder beneath the standalone text file.

Select nested-notes.
Use the new-file control to create first.txt.

The first nested file should now appear beneath nested-notes.

Enter First nested qualification note. in first.txt.
Save first.txt.

The saved file should contain the first nested sentence.

Use the new-file control to create second.txt inside nested-notes.

The nested folder should now contain two text files.

Enter Second nested qualification note. in second.txt.
Save second.txt.

The folder now gives Context Bridge two nested paths to discover.

Open Ubuntu's application search.
Type Files.
Select Ubuntu Files.
Navigate to the Context Bridge source folder that remains open in VS Code.
Open qualification-test-set.
Right-click nested-notes.
Select the option that creates a compressed archive.

The archive dialog should now ask for a format and filename.

Choose ZIP as the archive format.
Enter nested-notes.zip as the archive name.
Confirm the archive creation.

You should now see single-note.txt. You should also see the nested-notes folder and nested-notes.zip.

Generate and inspect the local queue

A local-only skill processes the test set without an AI provider or API key. This isolates file handling from the provider work reserved for a later project.

Return to Firefox.
Use the sidebar source control for an individual file.
Select single-note.txt from qualification-test-set.

The sidebar should show the standalone filename as an added source.

Use the sidebar source control for a folder.
Select nested-notes.

The sidebar should preserve the nested source paths. It should account for both text files.

Use the sidebar source control for an archive.
Select nested-notes.zip.

The sidebar should identify the archive source. Its expanded contents should correspond to the nested folder.

Select an implemented local-only skill that does not request an API key.
Generate the queue with the implemented queue control.

You should see at least one generated chunk in the queue. This proves the local processing path reached an observable result.

Open the first generated chunk.
Confirm that its source identity matches an item from the test set.
Confirm that its position follows the displayed source order.
Read the chunk to confirm that the text remains understandable.

Queue missing a test source?

Confirm that the standalone file still appears in the source area.
Confirm that the nested folder still reports two text files.
Confirm that the archive still exposes the nested content.
Regenerate the queue with the same local-only skill.

Help me diagnose the missing local source.

How should I grade each result?

Use pass when the capability works through its expected path.

Use degraded pass when the capability completes through a fallback or workaround.

Use fail when the capability cannot produce its required result.

Switch back to VS Code.
Select ubuntu-qualification.md from the file sidebar.
Add one result line for local text-file input.
Add one result line for nested-folder paths.
Save ubuntu-qualification.md.

The report should now capture the two non-archive input paths.

Add one result line for ZIP expansion.
Add one result line for local queue generation.
Save ubuntu-qualification.md.

The report should now show four local pipeline results. Each result should use pass, degraded pass, or fail.

Hand off the first chunk

The queue proves that Context Bridge can process the local inputs. The handoff proves that generated content can cross into the open NextWork editor.

Before you send the chunk, what do you expect to appear in the NextWork input? Hold that prediction before the check.

Return to Firefox.
Select the first generated chunk in Context Bridge.
Focus the open NextWork input.
Use the implemented handoff control to send the selected chunk.

If readable chunk text appears in NextWork, classify the handoff as pass. The visible text proves that direct insertion works.

If the NextWork input stays empty, the direct insertion path has fallen short. The clipboard fallback now provides the degraded path.

Use the extension's clipboard fallback for the same first chunk.
Focus the open NextWork input again.
Press Ctrl+V.

If readable chunk text appears after the paste, classify the handoff as degraded pass. If no readable text arrives, classify it as fail.

No text reaching NextWork?

Confirm that the cursor is active inside the intended NextWork input.
Retry the clipboard fallback with the same first chunk.
Record a failed handoff if the input remains empty.

Help me diagnose the failed handoff.

Switch back to VS Code.
Select ubuntu-qualification.md.
Add the handoff classification.
Save ubuntu-qualification.md.

Your report should now contain results for text-file input and nested-folder paths. It should also contain results for ZIP expansion, queue generation, and NextWork handoff.

That is the offline flight path proven. Context Bridge has processed local sources and completed a NextWork handoff on Ubuntu.

Next, you will turn this functional result into a security baseline by reviewing dependencies, generated permissions, and browser traffic.

Review Security and Privacy

Your local workflow now reaches NextWork from Ubuntu. That functional pass gives you something real to protect.

A working build can still carry unsafe dependencies. It can also request excessive browser access or make unexpected network calls.

In this step, get ready to:

Record the dependency audit findings.
Review the generated extension access.
Observe browser traffic during a local-only conversion.

Audit the locked dependencies

A dependency audit checks the restored package tree against known vulnerability reports. This check records evidence without changing the inherited dependency decisions.

Switch back to the VS Code terminal from earlier.

Before you run the audit, predict whether it will return a clean report or findings that need later remediation.

Check the locked dependency tree by running this command:

npm audit

What does this audit do?

The npm audit command submits the dependency description to the configured package registry. It reports known vulnerabilities in the installed dependency tree.

A non-zero exit status can mean the audit found vulnerabilities. Treat that result as qualification evidence.

Your terminal now shows the audit summary. The summary may report zero vulnerabilities or findings grouped by severity.

Add the reported vulnerability counts to ubuntu-qualification.md.
Add every reported severity to ubuntu-qualification.md.
Record zero for any severity with no findings.
Leave the dependency tree unchanged by skipping automatic audit remediation.
Save ubuntu-qualification.md.
Confirm the report now includes the audit counts plus their severities.

Audit stopped or returned findings?

Vulnerability findings are a valid qualification result. Record them without applying an automatic fix.

A registry connection failure means the audit did not complete. Restore internet access before retrying the audit.

Help me diagnose an npm audit that could not complete.

Review generated extension access

The generated manifest defines the browser permissions that Firefox enforces for the temporary extension. Reviewing the build output exposes access that may need source review.

Return to the VS Code workspace from earlier.
Select .output/firefox-mv2/manifest.json from the workspace file list.
Review every generated permission entry.
Review every generated host-access entry.
Record the complete access list in ubuntu-qualification.md.
Mark each unexplained wildcard for source review.
Mark each unexplained provider host for source review.
Save ubuntu-qualification.md.

Your report now lists the access generated into the exact Firefox build you loaded. Every unexplained wildcard or provider host has a visible review status.

Test the local network boundary

A privacy boundary shows whether a local-only conversion stays local. The debugger's Network panel captures requests made while the extension processes the test file.

Return to Firefox from earlier.
Load about:debugging from the Firefox address bar.
Select This Firefox.
Select Inspect for Context Bridge.
Select Network in the extension debugger.
Clear the existing network entries.

Before you repeat the conversion, predict whether the local-only skill will contact an AI provider or another unrelated external service.

Repeat a small conversion of the short text file with the implemented local-only skill.

The Network panel now contains the requests made by the extension during this conversion. An empty request list is also a valid observation.

Separate the traffic sources

The earlier npm audit check contacted the configured npm registry from the terminal. That registry traffic belongs to the dependency audit.

The debugger records traffic from the extension conversion. Keeping these sources separate prevents registry access from becoming a false privacy finding.

Review every request captured during the local-only conversion.
Record every observed extension request in ubuntu-qualification.md.
Record that no extension requests were observed when the list remains empty.
Record whether any AI-provider request appeared.
Record whether any unrelated external request appeared.
Mark every unexpected request for source review.
Distinguish the earlier npm registry traffic from the extension traffic.
Save ubuntu-qualification.md.

A local-only pass supports the privacy boundary when no AI-provider or unrelated external request appears. Any unexpected request becomes evidence for the no-go side of the report.

Network evidence looks incomplete?

Keep the extension debugger open while repeating the conversion.
Clear the Network panel immediately before the local-only test.
Confirm the short text file reaches the local queue before reviewing the request list.

Help me verify the extension Network test.

Before you make the final decision, predict whether the combined audit, access, and network evidence supports a go or no-go Ubuntu baseline.

Review ubuntu-qualification.md from top to bottom.
Set the baseline decision to go or no-go from the recorded evidence.

Your report now contains the audit counts plus severities. It also contains the generated access review plus every observed extension request separated from npm registry traffic.

You now have a defensible Ubuntu baseline. Its go or no-go decision is tied to recorded evidence.

Secret mission

Prove Cold-Start Recovery

A temporary Firefox add-on lasts only for the current browser session. Prove that Context Bridge can recover from a cold restart with a fresh build plus a local handoff. Record the recovery time plus any lost state in your qualification report.

Clean Up Your Resources

Your local qualification created no ongoing costs. Choose whether to keep the baseline ready, pause your work, or remove its disposable resources.

Resources you used:

The node_modules folder containing the restored locked dependencies.
The .output folder containing the fresh Firefox MV2 build.
The Context Bridge temporary add-on loaded from .output/firefox-mv2/manifest.json.

Keep everything running

No action is needed. Choose this if you plan to use the qualification baseline in later projects.

Keep Firefox open to preserve the temporary Context Bridge add-on in the current session.
Retain node_modules to skip another locked dependency restoration.
Retain .output for another temporary installation.
Preserve ubuntu-qualification.md as your Ubuntu baseline report.

Pause - I'll come back to this later

Shut down the running applications to free system memory. Your qualification files remain on disk.

Close Firefox.
Close Visual Studio Code.

When Firefox starts again, the temporary add-on is absent. Your completed cold-start procedure shows how to restore it.

Delete - I don't want to use this again

Remove each disposable project resource below. Keep the inherited source as your clean starting point.

Switch back to Firefox at about:debugging.
Select This Firefox in the left sidebar.
Click Remove beside Context Bridge.
Open Ubuntu Files from Ubuntu's application search.
In Ubuntu Files, navigate to the Context Bridge source folder that is already open in Visual Studio Code.
Delete the node_modules folder from that source folder.
Delete the .output folder from that source folder.
Confirm neither node_modules nor .output appears in Ubuntu Files.

Firefox no longer lists Context Bridge under This Firefox. Ubuntu Files no longer lists the generated dependency or build folders.

Keep the complete source folder with its unchanged package-lock.json.
Keep the ubuntu-qualification.md report as qualification evidence.

The nvm installation manages your Node.js runtime. This toolchain can stay installed for later projects.

Nice Work!

You made it! You qualified the expanded Context Bridge workflow on Ubuntu through a full Firefox cold-start recovery. Your report now separates proven local behavior from provider work that still needs dedicated testing.

You've learned how to:

Restore a reproducible Node.js toolchain on Ubuntu. You also preserved the inherited locked dependency graph during restoration.
Produce a Firefox MV2 production build with WXT. You temporarily loaded the build into your existing Firefox profile. You confirmed that the expanded sidebar appeared beside an open NextWork project.
Demonstrate the local pipeline across every prepared source type. You checked text-file input. You checked nested-folder paths. You checked ZIP archive expansion. You verified the chunk queue. You completed the NextWork handoff. You captured dependency findings in ubuntu-qualification.md. You added permission findings. You recorded network observations.
Secret Mission: Prove cold-start recovery after a Firefox restart. You rebuilt the extension. You reloaded the temporary add-on. You repeated the text-file-to-NextWork handoff. You recorded the recovery result in ubuntu-qualification.md.

Ready to quiz yourself?