nex-code 0.5.6 → 0.5.8

package/README.md

@@ -22,7 +22,7 @@
   <img src="https://img.shields.io/badge/Ollama_Cloud-supported-brightgreen.svg" alt="Ollama Cloud: supported">
   <img src="https://img.shields.io/badge/node-%3E%3D18-brightgreen.svg" alt="Node >= 18">
   <img src="https://img.shields.io/badge/dependencies-2-green.svg" alt="Dependencies: 2">
-  <img src="https://img.shields.io/badge/tests-3920-blue.svg" alt="Tests: 3920">
+  <img src="https://img.shields.io/badge/tests-3929-blue.svg" alt="Tests: 3920">
   <img src="https://img.shields.io/badge/VS_Code-extension-007ACC.svg" alt="VS Code extension">
 </p>
 
@@ -140,6 +140,14 @@ DEFAULT_PROVIDER=ollama
 DEFAULT_MODEL=devstral-2:123b
 ```
 
+**Env file precedence.** nex-code loads `.env` from three places in this order:
+
+1. Install directory `.env` — non-override, fills blanks only
+2. `~/.nex-code/.env` — **override**, wins over ambient `process.env`
+3. Current working directory `.env` — non-override, cannot clobber the global config
+
+`~/.nex-code/.env` is the authoritative location for long-lived config like `OLLAMA_API_KEY`. The `override:true` on that file exists so that a rotated key written there takes effect on the next `nex-code` launch, even when nex-code is spawned by a long-running parent process (systemd daemon, supervisor agent, test runner) whose own environment was captured earlier and is now stale. If you rotate an API key, update `~/.nex-code/.env` **and** restart any long-running daemon that spawns nex-code — the `override:true` fixes subprocess launches but cannot refresh the parent's own captured `process.env`.
+
 **Install from source:**
 
 ```bash
@@ -291,6 +299,21 @@ Multi-goal prompts auto-decompose into parallel sub-agents. Up to 5 agents run s
 nex-code --task "fix type errors in src/, add JSDoc to utils/, update CHANGELOG"
 ```
 
+### Background Agents
+
+Sub-agents can run non-blocking in isolated forked processes. The main agent continues working while background workers complete, then results are automatically injected into the conversation.
+
+```
+# The model decides when to use background:true — no extra syntax needed.
+# Example: the model might run the linter in background while explaining code.
+spawn_agents([
+  { task: "run the linter and report errors", background: true },
+  { task: "explain the auth module" }   ← main agent answers this immediately
+])
+```
+
+Background agents are shown in the spinner: `● Thinking [1 bg agent running]`. Results appear as `✓ Background agent done: …` when workers finish.
+
 ### Autoresearch
 
 Autonomous optimization loops: edit -> experiment -> keep/revert, on a dedicated branch.