Nano-Collective/nanocoder

Description When no valid explicit nanocoder.cliPath overrides discovery, plugins/vscode/src/cli-discovery.ts:50-60 iterates over workspace folders checking for path.join(folder.uri.fsPath, 'dist', 'cli.js'). If this file exists, it returns node <folder>/dist/cli.js. If a user opens an unrelated project in VS Code that compiles a script to dist/cli.js, Nanocoder treats that foreign script as the Nanocoder CLI and executes it with --acp. Environment OS: Linux (reviewed); macOS / Windows potentially affected Node version: >= 22.0.0 Nanocoder version: 1.31.0 Steps to Reproduce Open any workspace project that outputs a build artifact to dist/cli.js (not Nanocoder). Ensure nanocoder.cliPath is not set. Start the Nanocoder extension. Check the process spawned by AcpProcessManager. Expected Behavior The local development fallback should verify that the project is Nanocoder (e.g. checking package.json for "name": "@nanocollective/nanocoder"). If it is not Nanocoder, it should skip the work

Description The extension provides a nanocoder.cwd configuration setting. AcpProcessManager and the top-level nanocoder.openConfig command respect this setting. However, multiple other components in the extension host hardcode vscode.workspace.workspaceFolders?.[0]?.uri.fsPath || process.cwd(). Consequently, new session creation (newSession), settings-panel inspection, and @ mention file searches default to the first workspace folder rather than the configured nanocoder.cwd. Environment OS: Linux (reviewed); macOS / Windows potentially affected Node version: >= 22.0.0 Nanocoder version: 1.31.0 Configuration: "nanocoder.cwd": "/custom/project/path" Steps to Reproduce Set "nanocoder.cwd" in VS Code settings to a specific subdirectory or secondary project path. Open a workspace where the first workspace folder differs from nanocoder.cwd. Start the extension and trigger session initialization (getOrCreateSession) or @ mention file search. Expected Behavior The extension should consiste

Description Summary In source/commands/memory.tsx, createMemoryCommand(options) allows callers to inject a custom memoryManager via options.memoryManager. However, when memoryManager is provided without an explicit options.summarizerService, the command instantiates SummarizerService using the no-arg constructor new SummarizerService(). Because SummarizerService defaults its constructor parameter to a new SemanticMemoryManager(), /memory accept saves accepted proposals to a disconnected default manager instead of the injected options.memoryManager. Location source/commands/memory.tsx#L185-L197 export function createMemoryCommand( options: MemoryCommandOptions = {}, ): Command { let memoryManager = options.memoryManager; let summarizerService = options.summarizerService; if (!memoryManager) { const manager = new SemanticMemoryManager(); memoryManager = manager; summarizerService ??= new SummarizerService(manager); } else { summarizerService ??= new SummarizerService(); //

Description nanocoder cli input box and text in it is almost similar color , which is ruining the user experience in white mode . Environment OS: (linux(fedora) Steps to Reproduce open nano coder cli in light mode try to type any command Expected Behavior the color of text and input box should be opposite to the text can be visible Actual Behavior the color of text and input box is similar Logs/Screenshots Additional Context I have searched existing issues to ensure this is not a duplicate I can reproduce this issue consistently This issue occurs with the latest version of nanocoder

Description With nanocoder.sessions.autoSave set to false, every interactive start deletes the artifacts/<session id>/ folder (implementation plan, task list and walkthrough) of every saved session whose artifacts are more than a day old. The same happens with nanocoder run without --plain. Those sessions are still in sessions.json and can still be resumed, but they come back without their Plan, Tasks and Walkthrough. The docs say the startup sweep only removes directories of sessions that were never saved (session-management.md, Session Artifacts). Root cause (links pinned to 8c50d68d): useAppInitialization.tsx#L624 fires sessionManager.cleanupOrphanedArtifacts() without initializing the session manager first. initialize() is the only thing that resolves the sessions directory. With autoSave off, useSessionAutosave never calls it. So readIndex() has no path. It falls through to rebuildIndex(), which fails and returns []. cleanupOrphanedArtifacts() then treats every artifact folder as