fix: move registerDefaultTools to constructor to prevent concurrent map writes

[dgageot]

Problem

registerDefaultTools() was called inside the RunStream() goroutine, which writes to the plain map[string]ToolHandlerFunc field r.toolMap. When multiple goroutines call RunStream on the same LocalRuntime concurrently (e.g. background agent sessions), this causes a fatal error: concurrent map writes panic.

Fix

Move the r.registerDefaultTools() call from RunStream() to NewLocalRuntime(), so the map is fully populated during single-threaded construction. All subsequent accesses in processToolCalls are read-only, which is safe for concurrent goroutines.

Why this is safe

• The handlers are method values on *LocalRuntime and never change.
• r.bgAgents is already initialized before registerDefaultTools() is called.
• No other code writes to r.toolMap after construction.

[docker-agent]

Review Summary

Assessment: 🟢 APPROVE

This is a correct concurrency fix. Moving registerDefaultTools() from the RunStream() goroutine to the NewLocalRuntime() constructor ensures that the toolMap is fully populated during single-threaded construction, preventing the fatal error: concurrent map writes panic when multiple goroutines call RunStream() concurrently.

What was verified:

• The r.bgAgents field is already initialized before registerDefaultTools() is called in the constructor
• The change maintains the correct initialization order
• All subsequent accesses to r.toolMap in processToolCalls() are read-only, which is safe for concurrent goroutines
• No other code writes to r.toolMap after construction

Concurrency safety:
✅ Single-threaded write during construction
✅ Concurrent read-only access during runtime
✅ No data races introduced

No issues found in the changed code.

[rumpl]

Background agent sessions are using the same runtime??

[dgageot]

As far as I understand, yes. I'm still trying to improve the code