Repository navigation
fix(demo): trust the workspace, so the demo is not blocked by a modal - #27
Merged
Merged
Conversation
A fresh npm Codespace came up untrusted: the startup terminal asked to execute code, VS Code raised "Do you trust the authors of the files in this folder?", and until it was answered the extension could not activate at all — no Drift panel, no analysis, no terminal, Restricted Mode in the status bar. Answering the modal started everything within seconds, which is the proof it was the only thing in the way. The container is a throwaway holding a fixture from this repository, which is the code the visitor came to watch Drift read, so the question has one sensible answer and asking it only costs the demo. Also corrects the secondary-sidebar comment: that setting only takes effect from the second window load, because the sidebar is laid out before devcontainer settings arrive. Confirmed still open on first attach. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
RodolpheKouyoumdjian
deleted the
fix/untrusted-workspace-blocks-demo
branch
September 11, 2026 22:51
RodolpheKouyoumdjian
added a commit
that referenced
this pull request
Sep 11, 2026
The settings shipped in #27 cannot work: `security.workspace.trust.*` is user-scope by design and VS Code ignores it from devcontainer, remote and workspace settings. A fresh Codespace built from that commit raised the same modal, so the three keys are removed rather than left in place looking like a fix. What actually triggers the prompt is timing. Creating a terminal counts as executing code, so a `postAttachCommand` terminal that starts before Codespaces has finished granting trust makes VS Code ask, and while that modal stands the extension never activates: no panel, no analysis, no terminal. Two of three Codespaces opened on 2026-09-11 hit it; the third had simply attached more slowly. The startup terminal now waits ten seconds first — time the demo was already spending on its first analysis. A wait is a mitigation, not a guarantee, so DEMO.md now says what to click if the question appears anyway. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Found re-testing the npm Codespace after the v0.1.4 extension release.
What happened
The Codespace came up untrusted. The startup terminal wants to execute code, so VS Code raised "Do you trust the authors of the files in this folder?" — and while that modal sat there:
postAttachCommandnever produced a terminal.Answering the modal started Drift within seconds ("Drift: Gathering evidence for axios" → "Drift: 1 file affected"), which shows it was the only blocker. The first Codespace I tested did not hit this, so it is intermittent — which is worse for a launch demo, not better.
Fix
The container is a throwaway holding a fixture from this repository — the very code the visitor opened it to watch Drift read.
Also
Corrects the
workbench.secondarySideBar.defaultVisibilitycomment. It only takes effect from the second window load: the secondary sidebar is laid out before devcontainer settings arrive (known Codespaces limitation). Verified still open on first attach; the setting is kept because it does work on reload.All 16 devcontainers regenerated;
node scripts/check-demos.mjs→ All demos OK.🤖 Generated with Claude Code