The VS Code extension runs core in-process (new Core(inProcessMessenger, this.ide) in VsCodeExtension.ts:294) and never wires up LLMLogFormatter to a file stream. The only code path that writes prompt.log is binary/src/index.ts:38, which is the CLI entrypoint.

The LLMLogger fires events and the console webview can display them, but nothing persists to disk. This means ~/.continue/logs/prompt.log is never written when using the VS Code extension.

This is easy to miss during development because the "Core Binary" debug launch config in .vscode/launch.json runs the binary alongside the extension, and that binary does wire up file logging. So contributors actively debugging get prompt logs, but end users and contributors running the extension normally never do. We didn't notice the gap until stepping away from the debug launch config.

This makes it difficult to:

• Debug prompt construction issues (system prompt content, token counts, tool definitions)
• Capture what's actually being sent to model providers
• Report bugs with evidence of what the model received

The fix is straightforward: wire up LLMLogFormatter with a file write stream in the VS Code extension path, same as the binary does. Risks to consider:

• File handle cleanup — VsCodeExtension has no deactivate() lifecycle hook. The write stream needs to be pushed onto context.subscriptions as a disposable so it closes on extension deactivation/reload.
• Concurrent writes — If someone runs the CLI binary alongside the extension, two processes append to the same file. This is a pre-existing risk from the binary path but worth noting.
• File growth — No log rotation exists in either path. Not a new problem but prompt logs can get large (3.8 MB observed over ~6 weeks of intermittent use).