Workspace isolation not initialized for Slack socket mode and snapshot resumes

[buger]

Summary

Workspace isolation is not being properly initialized when running in Slack socket mode, even when workspace.enabled: true is configured. This causes:

1. Git checkouts to happen in .visor/worktrees/ but NOT be added to the workspace
2. AI provider (ProbeAgent) to only have access to the Visor repo directory, not the checkout paths
3. AI searches to fail finding code in checked-out repositories

Root Cause

There are two issues:

1. resumeFromSnapshot() doesn't call initializeWorkspace()

In src/state-machine-execution-engine.ts, the resumeFromSnapshot() function (line ~1049) creates a new context via buildEngineContextForRun() but never calls initializeWorkspace(context).

When Slack socket runner resumes from a snapshot (src/slack/socket-runner.ts line 320-336), it uses resumeFromSnapshot() which skips workspace initialization entirely.

2. Potential issue with cold runs

Even for cold runs where executeChecks() → executeGroupedChecks() → initializeWorkspace() should be called, workspace is not being initialized. This needs further investigation.

Evidence from logs

[GitCheckout]   _parentContext exists: true
[GitCheckout]   workspace exists: false
[GitCheckout] Workspace not enabled, skipping addProject

And from AI provider:

[DEBUG] 🗂 ProbeAgent workspace config:
[DEBUG]    path (cwd): /home/buger/projects/visor2
[DEBUG]    allowedFolders[0]: /home/buger/projects/visor2

The workspace is clearly not initialized despite workspace.enabled: true in config:

workspace:
  enabled: true
  cleanup_on_exit: true

Impact

• Git checkouts succeed (to .visor/worktrees/worktrees/TykTechnologies-tyk-HEAD-...)
• But workspace.addProject() is never called
• AI provider falls back to using only the Visor repo directory
• AI cannot search/find code in the checked-out repositories

Proposed Fix

1. Add initializeWorkspace(context) call to resumeFromSnapshot() after context creation
2. Investigate why cold runs also don't initialize workspace
3. Add workspace initialization to any code path that creates a new EngineContext

Related Files

• src/state-machine-execution-engine.ts: executeGroupedChecks() (line ~276-278), resumeFromSnapshot() (line ~1049)
• src/state-machine/context/build-engine-context.ts: initializeWorkspace()
• src/slack/socket-runner.ts: Slack message handling
• src/providers/git-checkout-provider.ts: Workspace integration
• src/providers/ai-check-provider.ts: Workspace detection for ProbeAgent

[probelabs]

Thank you for this detailed bug report! I've analyzed the code and can confirm the issue you've identified.

Analysis

Confirmed Issues

1. Missing initializeWorkspace() in resumeFromSnapshot()

I can confirm that resumeFromSnapshot() in src/state-machine-execution-engine.ts (line 1049) creates a new context via buildEngineContextForRun() but never calls initializeWorkspace(context). This is a clear bug.

In contrast, the normal execution path in executeGroupedChecks() (line 276-278) correctly calls:

const { initializeWorkspace } = require('./state-machine/context/build-engine-context');
await initializeWorkspace(context);

2. Workspace Detection in GitCheckoutProvider

The GitCheckoutProvider (line 145-156) correctly checks for workspace:

const workspace = (context as any)?._parentContext?.workspace;
if (workspace?.isEnabled()) {
  // Add project to workspace
}

However, since resumeFromSnapshot() never initializes the workspace, context.workspace is undefined, causing the log message you see: "Workspace not enabled, skipping addProject".

3. AI Provider Workspace Configuration

The AI provider's workspace configuration depends on the workspace being properly initialized in the context. Without it, the AI only has access to the main Visor repository directory.

Root Cause Summary

The issue is straightforward: resumeFromSnapshot() skips the workspace initialization step that executeGroupedChecks() performs. This affects:

• Slack socket mode resumes (primary impact)
• Any other snapshot resume scenarios

Proposed Fix

The fix is simple and follows the existing pattern in executeGroupedChecks(). In resumeFromSnapshot(), after the context is built (around line 1068), add:

// Initialize workspace isolation (if enabled)
const { initializeWorkspace } = require('./state-machine/context/build-engine-context');
await initializeWorkspace(context);

This should be added after the context creation and before the frontends initialization, mirroring the order in executeGroupedChecks().

Questions for Clarification

1. Cold runs issue: You mentioned that even cold runs don't initialize workspace. Can you provide more details about this? The code shows executeGroupedChecks() should call initializeWorkspace(). Are you seeing this in Slack socket mode cold runs specifically, or in CLI runs as well?

2. Reproduction steps: Could you share a minimal configuration that reproduces the issue? This would help verify the fix works correctly.

3. Workspace cleanup: When resuming from snapshot, should the workspace be re-initialized (fresh) or should we attempt to reuse the existing workspace from the previous run?

Next Steps

1. Add initializeWorkspace(context) call to resumeFromSnapshot()
2. Add logging to verify workspace initialization in both cold and resume paths
3. Test with Slack socket mode to verify the fix

References

• src/state-machine-execution-engine.ts:276-278 – Correct workspace initialization in executeGroupedChecks
• src/state-machine-execution-engine.ts:1049-1068 – resumeFromSnapshot missing workspace initialization
• src/state-machine/context/build-engine-context.ts:123-162 – initializeWorkspace function
• src/providers/git-checkout-provider.ts:145-156 – Workspace detection in GitCheckoutProvider
• src/slack/socket-runner.ts:300-309 – Slack snapshot resume path

---

Powered by Visor from Probelabs

💡 TIP: You can chat with Visor using /visor ask <your question>

[buger]

Additional Context: Intermittent Behavior

The user reports that:

• Sometimes workspace works, sometimes it doesn't
• Retrying usually makes it work the second time

This strongly suggests the issue is specifically with snapshot resume:

Theory

1. First message in a new Slack thread → Cold run path → executeChecks() → executeGroupedChecks() → initializeWorkspace() → ✅ Works

2. Subsequent message in same thread → Snapshot exists → resumeFromSnapshot() → No initializeWorkspace() → ❌ Fails

3. Retry in new thread → No snapshot → Cold run → ✅ Works again

Evidence

In src/slack/socket-runner.ts (lines 291-337):

const waiting = channel && threadTs ? mgr.getWaiting(channel, threadTs) : undefined;
const path = waiting?.snapshotPath;
// ...
if (path) {
  try {
    await resumeFromSnapshot(runEngine, snapshot, cfgForRun, {...});
    return;  // <-- Returns early, never calls cold run path
  } catch (e) {
    // Falls back to cold run only if resume FAILS
  }
}
// Cold run (no snapshot) - workspace IS initialized here
await runEngine.executeChecks({...});

Confirmation Needed

@buger Can you confirm:

1. Does workspace work on the first message in a brand new Slack thread?
2. Does it fail on follow-up messages in the same thread?
3. When you "retry", are you starting a new thread or continuing in the same one?

Fix

The fix should add initializeWorkspace(context) to resumeFromSnapshot() after context creation (around line 1067 in state-machine-execution-engine.ts):

const context = buildEngineContextForRun(...);

// Add this:
const { initializeWorkspace } = require('./state-machine/context/build-engine-context');
await initializeWorkspace(context);