@ducci/jarvis 1.0.22 → 1.0.24

package/docs/findings/006-malformed-tool-schema.md

@@ -0,0 +1,118 @@
+# Finding 006: Malformed Tool Schema Poisons Every Subsequent Request
+
+**Date:** 2026-02-27
+**Severity:** High — permanently breaks all model calls for the session until tools.json is manually repaired
+**Status:** Fixed
+
+---
+
+## What Happened
+
+During a session installing security tools (Nuclei, Subfinder, Naabu), the agent called `save_tool` to create a custom `scan` tool. The model passed the `parameters` field as a **JSON-serialized string** instead of a JSON object:
+
+```json
+"parameters": "{\"type\":\"object\",\"properties\":{\"domain\":{\"type\":\"string\",...}}}"
+```
+
+`save_tool` stored this verbatim — no validation occurred. The malformed tool definition was written to `~/.jarvis/data/tools/tools.json` as tool index 12.
+
+On the very next model call (within the same run), Jarvis reloaded tools after `save_tool` completed (`toolsModified = true`) and sent all tool definitions to the provider. OpenRouter's provider API returned:
+
+```
+400 Provider returned error
+[{'type': 'dict_type', 'loc': ('body', 'tools', 12, 'function', 'parameters'),
+  'msg': 'Input should be a valid dictionary', 'input': '{"type":"object",...}'}]
+```
+
+Every subsequent user message — including trivial ones like "Was ist schief gegangen?" and "Wie ist deine session id" — also failed with the same 400. The malformed tool was permanently in `tools.json` and included in every model request.
+
+---
+
+## Root Cause
+
+### 1. `save_tool` did not validate `parameters`
+
+The `save_tool` code stored `args.parameters` directly into `tools.json` without checking its type. The OpenAI tool-calling spec requires `parameters` to be a JSON Schema object (a dictionary). When a model passes a JSON string instead of an object — a common mistake with weaker models — the result is a permanently malformed tool definition.
+
+### 2. `getToolDefinitions` sent all tools to the provider without validation
+
+`getToolDefinitions` returned all tool definitions unconditionally. A single malformed tool poisoned every request that included the tools list — which is every request, since tool definitions are always sent.
+
+These two gaps compound each other: the first allows bad data in, the second ensures it breaks everything downstream.
+
+---
+
+## Why it Persists Across All Subsequent Messages
+
+Every `handleChat` call loads tools fresh from `tools.json` via `loadTools()`. The malformed `scan` tool is always in the list. Every model call sends all tool definitions. The provider rejects every request. The session is stuck until `tools.json` is manually repaired.
+
+---
+
+## Intermittent Behavior
+
+The failure is not always immediate. In the debugging session, two tool calls succeeded in later runs before the 400 fired. This is consistent with free/preview model providers (nvidia via OpenRouter) applying schema validation inconsistently across backend instances. The bug is therefore not "always broken" but **reliably broken under load** — which is harder to detect and debug than a consistent failure.
+
+---
+
+## Fix
+
+Two targeted changes to `src/server/tools.js`.
+
+### 1. `save_tool` validates and auto-corrects `parameters`
+
+Before writing to `tools.json`, the `save_tool` code now:
+- If `parameters` is a string, attempts `JSON.parse()` — models commonly serialize the object when they should pass it directly. If parsing succeeds and yields an object, the corrected value is used silently.
+- If `parameters` is still not a plain object after the attempted parse, returns an error immediately with a clear message. Nothing is written to disk.
+
+```js
+let parameters = args.parameters;
+if (typeof parameters === 'string') {
+  try {
+    parameters = JSON.parse(parameters);
+  } catch {
+    return { status: 'error', error: 'parameters must be a JSON Schema object, not a string. Pass the object directly, not as a JSON-serialized string.' };
+  }
+}
+if (typeof parameters !== 'object' || parameters === null || Array.isArray(parameters)) {
+  return { status: 'error', error: 'parameters must be a JSON Schema object (e.g. { type: "object", properties: {...} }).' };
+}
+```
+
+### 2. `getToolDefinitions` filters out malformed tools
+
+`getToolDefinitions` now validates `parameters` on each tool before including it in the definitions sent to the provider. A tool with a non-object `parameters` is skipped with a `console.warn`, not thrown — this is a defence-in-depth guard, not a primary error path.
+
+```js
+export function getToolDefinitions(tools) {
+  const defs = [];
+  for (const [name, t] of Object.entries(tools)) {
+    const params = t.definition?.function?.parameters;
+    if (typeof params !== 'object' || params === null || Array.isArray(params)) {
+      console.warn(`[tools] Skipping tool '${name}': parameters is not a valid object (got ${typeof params})`);
+      continue;
+    }
+    defs.push(t.definition);
+  }
+  return defs;
+}
+```
+
+Together: Fix 1 prevents malformed tools from entering `tools.json`. Fix 2 ensures that even if a malformed tool somehow ends up in `tools.json` (e.g. from an older version, manual edit, or a bug that slips through), it is silently excluded from every model request rather than poisoning the session.
+
+---
+
+## Secondary Issue: Agent Hallucinated Successful Action
+
+In the run that preceded the `save_tool` call, the agent responded with:
+
+> "The scanning script has been created at /root/.jarvis/projects/cybersecurity/scan.sh."
+
+No such file was ever created — the agent had only installed Nuclei successfully. This hallucination forced the next run to attempt recovery via `save_tool`, which is where the malformed tool was introduced. The hallucination itself is a model-quality issue with the free nvidia model, not a Jarvis bug.
+
+---
+
+## Outcome
+
+- `save_tool` auto-corrects the common case (string instead of object) and rejects the rest with a clear error before writing to disk
+- A pre-existing malformed tool in `tools.json` no longer poisons model requests — it is silently skipped per call
+- Sessions are no longer permanently broken by a single bad `save_tool` call

package/docs/findings/007-telegram-errors-and-handoff-stalling.md

@@ -0,0 +1,271 @@
+# Finding 007: Telegram Error Opacity, Empty Responses, and Handoff Stalling
+
+**Date:** 2026-02-28
+**Severity:** High — caused "Sorry, something went wrong" with no context, silent empty responses, and 40+ wasted iterations on a stuck task
+**Status:** Fixed
+
+---
+
+## Observed Session
+
+The session (`fdb3fb46`) ran on a Linux server using `nvidia/nemotron-3-nano-30b-a3b:free`. The user asked Jarvis to implement a cybersecurity scanning project and run a scan against `https://dviet.de`. The session produced 10 agent runs over approximately 2 hours, including 4 consecutive handoff runs that made no real progress, two "Sorry, something went wrong" errors in Telegram, and one completely silent (empty) Telegram message.
+
+---
+
+## What Happened — Full Run Sequence
+
+| Run | Trigger | Status | Telegram received |
+|-----|---------|--------|-------------------|
+| 1 | "Hi" | ok | "Hello Duc! 👋" |
+| 2 | "Weißt du wo das cybersecurity Projekt liegt?" | ok (9 iterations) | Location found |
+| 3 | "Kannst du das readme lesen..." | ok | README analysis |
+| 4 | "Yes implement the missing pieces..." | **format_error** | **Empty message (silent)** |
+| 5 | "What exactly went wrong?" (handoff 1) | checkpoint_reached | — (internal handoff loop) |
+| 6 | handoff 2 | checkpoint_reached | — (internal) |
+| 7 | handoff 3 | checkpoint_reached | — (internal) |
+| 8 | handoff 4 | **model_error** | **"Sorry, something went wrong: ..."** |
+| 9 | "What is your session id" | ok | Session ID |
+| 10 | "Do exec ls" | **model_error** | **"Sorry, something went wrong: ..."** |
+
+---
+
+## Issue 1: Generic "Sorry, something went wrong" with no context
+
+### What happened
+
+Runs 8 and 10 failed with `model_error: Empty choices array` — the nvidia free model returned a response with `choices: []`, producing no content at all. When `handleChat` threw an error, the Telegram channel's catch block sent:
+
+```
+Sorry, something went wrong. Please try again.
+```
+
+This is maximally unhelpful. The user has no idea whether the model failed, whether a tool crashed, whether the session is broken, or whether retrying will help.
+
+### Root cause
+
+The catch block in `src/channels/telegram/index.js` used a hardcoded string regardless of the actual error:
+
+```js
+} catch (e) {
+  console.error(`[telegram] agent error chat_id=${chatId}: ${e.message}`);
+  await ctx.reply('Sorry, something went wrong. Please try again.');
+  clearInterval(typingInterval);
+  return;
+}
+```
+
+The error message was logged to `console.error` (only visible in server logs, not to the user) and discarded.
+
+### Fix (`src/channels/telegram/index.js`)
+
+Pass `e.message` to the user reply:
+
+```js
+const errText = e.message
+  ? `Sorry, something went wrong: ${e.message}`
+  : 'Sorry, something went wrong. Please try again.';
+await ctx.reply(errText).catch(() => {});
+```
+
+The `.catch(() => {})` guards against a second failure when the Telegram API itself is unreachable — without it, a failed `ctx.reply` inside the catch block would throw an unhandled rejection.
+
+---
+
+## Issue 2: Empty Telegram message on `format_error`
+
+### What happened
+
+Run 4 ended with `format_error` — the model produced a non-JSON final response and all three recovery attempts (fallback model, nudge retry) also failed. The agent returned with `response: ""` (empty string). The Telegram handler then called:
+
+```js
+const text = result.response;  // ""
+await ctx.reply(text);          // ctx.reply("") — Telegram silently rejects empty messages
+```
+
+The user saw nothing. No error, no confirmation, no indication that anything had happened. From their perspective the message was sent and never received a reply.
+
+### Root cause
+
+The delivery block in `src/channels/telegram/index.js` used `result.response` directly without guarding against empty or null values. When `format_error` returns an empty string, `ctx.reply("")` is called and Telegram's API rejects it silently (HTTP 400 from Telegram, swallowed by grammy).
+
+Additionally, the error log in the delivery catch block used `result.response.length`, which would throw a `TypeError` if `result.response` was `null` rather than `""`.
+
+### Fix (`src/channels/telegram/index.js`)
+
+Guard with `?.trim()` and a fallback message:
+
+```js
+const text = result.response?.trim()
+  || 'The agent encountered an error and could not produce a response. Please try again.';
+```
+
+Also updated the delivery catch block to not reference `result.response.length` (which crashes on null).
+
+---
+
+## Issue 3: `failedApproaches` memory lost across handoff runs
+
+### What happened
+
+Runs 5, 6, 7, and 8 were all consecutive handoff runs triggered by a single user message ("What exactly went wrong?"). Each run correctly produced a `failedApproaches` array in its checkpoint — for example, "nuclei scan command timed out". However, the resume message for the next run was built using only the **current run's** `failedApproaches`:
+
+```js
+if (run.checkpoint.failedApproaches && run.checkpoint.failedApproaches.length > 0) {
+  resumeContent += `\n\n[System: The following approaches were tried and failed in the previous run — ...]`
+  // ↑ only the last run's failures, not all previous runs
+}
+```
+
+Run 6 started knowing about run 5's failures. Run 7 started knowing about run 6's failures — but had forgotten run 5's. Run 8 started knowing about run 7's failures — but had forgotten runs 5 and 6. The model could only see one run of history at a time and kept rediscovering and re-attempting strategies it had already tried.
+
+The session JSONL log shows runs 5, 6, 7, and 8 all executing nearly identical tool call sequences:
+
+- `nuclei -update-templates`
+- `nuclei -h`
+- `mkdir -p results/dviet.de`
+- `which node`
+- `ls -al /usr/local/share/nuclei` → error (directory doesn't exist)
+- `echo -e '#!/bin/bash...'` → broken scan.sh
+- `nuclei -silent ... -u https://dviet.de` → **60s timeout**
+- `nmap -sV -p 80,443 dviet.de` → host down
+- `nuclei -silent -t http-title ...` → **60s timeout**
+
+32 tool calls in run 8 alone, across only 3 model iterations — the model was dumping the same 10-call batch per iteration, learning nothing.
+
+### Fix (`src/server/agent.js`, `src/server/sessions.js`)
+
+**1.** Added `failedApproaches: []` to `session.metadata` in `createSession()`. This gives old sessions a graceful upgrade path (the field will be initialized to `[]` on the first new user message that resets handoff state).
+
+**2.** On every new user message, `failedApproaches` is reset alongside `handoffCount`:
+
+```js
+session.metadata.handoffCount = 0;
+session.metadata.failedApproaches = [];
+```
+
+**3.** After each `checkpoint_reached` run, the current run's failures are pushed onto the session-level accumulator:
+
+```js
+if (run.checkpoint.failedApproaches && run.checkpoint.failedApproaches.length > 0) {
+  if (!session.metadata.failedApproaches) session.metadata.failedApproaches = [];
+  session.metadata.failedApproaches.push(...run.checkpoint.failedApproaches);
+}
+```
+
+**4.** The resume message uses the full accumulated list instead of just the last run's:
+
+```js
+const allFailedApproaches = session.metadata.failedApproaches || [];
+if (allFailedApproaches.length > 0) {
+  resumeContent += `\n\n[System: The following approaches were tried and failed in previous runs — do not repeat them:\n${allFailedApproaches.map((a, i) => `${i + 1}. ${a}`).join('\n')}]`;
+}
+```
+
+The message changed from "in the **previous run**" to "in **previous runs**" to accurately reflect the scope.
+
+---
+
+## Issue 4: Zero-progress handoffs not detected
+
+### What happened
+
+Runs 5, 6, and 7 all hit `checkpoint_reached` with nearly identical `remaining` fields. Each run used 10 full iterations yet made no real progress — the `remaining` list after run 7 was essentially the same as after run 5. The handoff loop continued spawning new runs until `maxHandoffs` was hit, burning 30 more iterations and about 90 minutes of wall time.
+
+The existing `maxHandoffs` limit (default 5) is the only backstop, but it doesn't distinguish between runs that make real progress and runs that achieve nothing. It allows up to 5 useless handoffs before stopping.
+
+### Root cause
+
+No comparison was made between consecutive `checkpoint.remaining` values. The handoff loop always continued as long as `handoffCount <= maxHandoffs`, with no check that the agent had actually made forward progress.
+
+### Fix (`src/server/agent.js`)
+
+Introduced a `previousRemaining` variable in the handoff loop. Before each handoff continuation, the current `checkpoint.remaining` (trimmed) is compared against the previous run's value. If they are identical, the session is stopped immediately with `intervention_required`:
+
+```js
+let previousRemaining = null;
+
+// ... inside handoff loop, after checkpoint_reached:
+const currentRemaining = (run.checkpoint.remaining || '').trim();
+if (previousRemaining !== null && currentRemaining === previousRemaining) {
+  finalStatus = 'intervention_required';
+  finalLogSummary = 'Zero progress detected: task state unchanged after a full run. Human intervention required.';
+  // log, strip, break
+}
+previousRemaining = currentRemaining;
+```
+
+This fires on the **second** handoff with identical remaining — one repeat is allowed because the model may be working on the same items in a different order. Identical remaining on two consecutive runs means it is genuinely stuck.
+
+**Effect on the debugging session**: instead of running 4 useless handoffs (runs 5–8), the agent would have stopped at run 6 with `intervention_required`, saving 20 iterations and about 60 minutes.
+
+---
+
+## Issue 5: `echo -e` creates broken shell scripts on Ubuntu
+
+### What happened
+
+The model attempted to create `scan.sh` using:
+
+```sh
+echo -e '#!/bin/bash\n# Simple wrapper...\n...'
+```
+
+On Ubuntu, the default shell for non-interactive commands is `/bin/dash`, not `/bin/bash`. `dash` does not support `echo -e` — it treats `-e` as a literal argument, so the file started with:
+
+```
+-e #!/bin/bash
+# Simple wrapper...
+```
+
+Every attempt to run `scan.sh` failed with:
+
+```
+/root/.jarvis/projects/cybersecurity/scan.sh: 1: -e: not found
+```
+
+The model detected the error on the first try, but each subsequent handoff run repeated the exact same broken creation command, presumably because the `echo -e` pattern was deep in the model's training distribution for "create a shell script".
+
+### Root cause
+
+The system prompt's `## exec Safety` section gave guidance about filesystem scans and `cat` vs `grep`, but said nothing about portable file creation. The `echo -e` pattern works on bash but not on sh/dash, and this distinction is invisible to a model working through `exec`.
+
+### Fix (`docs/system-prompt.md`)
+
+Added a bullet to `## exec Safety`:
+
+```
+- **Writing multi-line files**: use `printf '...'` or a heredoc (`cat <<'EOF' > file`) instead of
+  `echo -e`. The `-e` flag is not portable — on Ubuntu `/bin/sh` it is treated as literal text,
+  corrupting the file.
+```
+
+---
+
+## What Was Not Changed
+
+- The `model_error: Empty choices array` path in `runAgentLoop` — this is a provider-side failure, no server-side fix can prevent the model from returning nothing. The fix is at the Telegram delivery layer (surfacing the error to the user), not at the agent layer.
+- The `maxHandoffs` limit — it remains as a hard cap. Zero-progress detection fires before `maxHandoffs` in the case of a truly stuck task, so the two mechanisms are complementary.
+- The `consecutiveFailures` detector and exact-match loop tracker — unchanged; they work alongside the new zero-progress check.
+- No per-session Perplexity call counter was added server-side.
+
+---
+
+## Secondary Observation: nuclei templates were present but never found
+
+Nuclei was installed at `/usr/local/bin/nuclei`. Its templates were at `/root/nuclei-templates` (visible in the `list_dir /root` output from run 2). However, the model never connected these two facts — it searched `/usr/local/share/nuclei`, `/root/.nuclei`, and various `/usr` subdirectories, missing the templates that were right there in `/root`.
+
+Running `nuclei -u https://dviet.de -t /root/nuclei-templates/...` (or just `nuclei -u https://dviet.de` with the templates auto-discovered from `~/nuclei-templates`) would likely have worked. The scan also failed because `nmap` reported "host seems down" for `dviet.de` — the host was either rate-limiting ICMP or the port scan was blocked. Using `nmap -Pn` to skip host discovery would have bypassed this.
+
+Neither of these is a Jarvis bug — they are model reasoning failures specific to this session and this free model. A more capable model would have spotted the template path and the nmap flag.
+
+---
+
+## Outcome
+
+| Fix | Files changed |
+|-----|--------------|
+| Better error text in Telegram catch block | `src/channels/telegram/index.js` |
+| Guard against empty response before `ctx.reply()` | `src/channels/telegram/index.js` |
+| Accumulate `failedApproaches` across all handoffs in `session.metadata` | `src/server/agent.js`, `src/server/sessions.js` |
+| Zero-progress handoff detection via `previousRemaining` comparison | `src/server/agent.js` |
+| Shell script writing guidance (`printf`/heredoc over `echo -e`) | `docs/system-prompt.md` |

package/docs/system-prompt.md

@@ -52,6 +52,7 @@ The `exec` tool runs real shell commands on the server. Use it responsibly:
 - **Use known paths.** Prefer `process.cwd()`, `$HOME`, or paths you already know over broad searches. Use `which <binary>` to locate executables.
 - **Prefer targeted reads.** Use `grep`, `head`, or `tail` instead of `cat` on files you haven't seen before. Large file output is truncated anyway — a targeted command gives you better signal.
 - **Avoid commands with unbounded runtime.** If a command could run indefinitely or scan an unknown-size tree, scope it first.
+- **Writing multi-line files**: use `printf '...'` or a heredoc (`cat <<'EOF' > file`) instead of `echo -e`. The `-e` flag is not portable — on Ubuntu `/bin/sh` it is treated as literal text, corrupting the file.
 
 ## Failure Recovery
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ducci/jarvis",
-  "version": "1.0.22",
+  "version": "1.0.24",
   "description": "A fully automated agent system that lives on a server.",
   "main": "./src/index.js",
   "type": "module",

package/src/channels/telegram/index.js

@@ -50,7 +50,10 @@ export async function startTelegramChannel(config) {
       result = await handleChat(config, sessionId, ctx.message.text);
     } catch (e) {
       console.error(`[telegram] agent error chat_id=${chatId}: ${e.message}`);
-      await ctx.reply('Sorry, something went wrong. Please try again.');
+      const errText = e.message
+        ? `Sorry, something went wrong: ${e.message}`
+        : 'Sorry, something went wrong. Please try again.';
+      await ctx.reply(errText).catch(() => {});
       clearInterval(typingInterval);
       return;
     }
@@ -64,7 +67,9 @@ export async function startTelegramChannel(config) {
 
     try {
       const MAX_TG = 4096;
-      const text = result.response;
+      // Guard against empty response (e.g. format_error returns empty string)
+      const text = result.response?.trim()
+        || 'The agent encountered an error and could not produce a response. Please try again.';
       if (text.length <= MAX_TG) {
         await ctx.reply(text);
       } else {
@@ -74,8 +79,8 @@ export async function startTelegramChannel(config) {
       }
       console.log(`[telegram] response sent chat_id=${chatId} length=${text.length}`);
     } catch (e) {
-      console.error(`[telegram] delivery error chat_id=${chatId} length=${result.response.length}: ${e.message}`);
-      await ctx.reply('Sorry, something went wrong. Please try again.');
+      console.error(`[telegram] delivery error chat_id=${chatId}: ${e.message}`);
+      await ctx.reply('Sorry, something went wrong sending the response. Please try again.').catch(() => {});
     } finally {
       clearInterval(typingInterval);
     }

package/src/server/agent.js

@@ -381,9 +381,10 @@ async function _runHandleChat(config, sessionId, userMessage) {
     session = createSession(systemPromptTemplate);
   }
 
-  // Append user message and reset handoff counter
+  // Append user message and reset handoff state
   session.messages.push({ role: 'user', content: userMessage });
   session.metadata.handoffCount = 0;
+  session.metadata.failedApproaches = [];
 
   // Resolves {{user_info}} in system prompt at runtime (never persisted)
   function prepareMessages(messages) {
@@ -399,6 +400,8 @@ async function _runHandleChat(config, sessionId, userMessage) {
   let finalResponse = '';
   let finalLogSummary = '';
   let finalStatus = 'ok';
+  // Tracks checkpoint.remaining from the previous handoff run to detect zero progress
+  let previousRemaining = null;
 
   try {
     // Handoff loop
@@ -449,6 +452,36 @@ async function _runHandleChat(config, sessionId, userMessage) {
         status: 'checkpoint_reached',
       });
 
+      // Accumulate failedApproaches from this run into session metadata so the
+      // full history of failed strategies is available across all handoff runs.
+      if (run.checkpoint.failedApproaches && run.checkpoint.failedApproaches.length > 0) {
+        if (!session.metadata.failedApproaches) session.metadata.failedApproaches = [];
+        session.metadata.failedApproaches.push(...run.checkpoint.failedApproaches);
+      }
+
+      // Zero-progress detection: if checkpoint.remaining is identical to the previous
+      // handoff's remaining, the agent completed a full run without making any progress.
+      // Stop immediately rather than burning more iterations on a stuck task.
+      const currentRemaining = (run.checkpoint.remaining || '').trim();
+      if (previousRemaining !== null && currentRemaining === previousRemaining) {
+        finalResponse = run.response;
+        finalLogSummary = 'Zero progress detected: task state unchanged after a full run. Human intervention required.';
+        finalStatus = 'intervention_required';
+
+        await appendLog(sessionId, {
+          iteration: 0,
+          model: config.selectedModel,
+          userInput: userMessage,
+          toolCalls: [],
+          response: finalResponse,
+          logSummary: finalLogSummary,
+          status: 'intervention_required',
+        });
+        session.messages.splice(runStartIndex, session.messages.length - runStartIndex - 1);
+        break;
+      }
+      previousRemaining = currentRemaining;
+
       // Check handoff limit
       session.metadata.handoffCount++;
       if (session.metadata.handoffCount > config.maxHandoffs) {
@@ -478,10 +511,12 @@ async function _runHandleChat(config, sessionId, userMessage) {
 
       // Resume with checkpoint.remaining as new prompt.
       // Guard against null/undefined in case the model omitted the field.
-      // Prepend any failed approaches so the next run doesn't repeat them.
+      // Use the full accumulated failedApproaches list across ALL handoff runs so the
+      // agent has complete memory of what has already been tried and failed.
       let resumeContent = run.checkpoint.remaining || 'Continue with the task.';
-      if (run.checkpoint.failedApproaches && run.checkpoint.failedApproaches.length > 0) {
-        resumeContent += `\n\n[System: The following approaches were tried and failed in the previous run — do not repeat them:\n${run.checkpoint.failedApproaches.map((a, i) => `${i + 1}. ${a}`).join('\n')}]`;
+      const allFailedApproaches = session.metadata.failedApproaches || [];
+      if (allFailedApproaches.length > 0) {
+        resumeContent += `\n\n[System: The following approaches were tried and failed in previous runs — do not repeat them:\n${allFailedApproaches.map((a, i) => `${i + 1}. ${a}`).join('\n')}]`;
       }
       session.messages.push({ role: 'user', content: resumeContent });
     }

package/src/server/sessions.js

@@ -22,6 +22,7 @@ export function createSession(systemPromptTemplate) {
   return {
     metadata: {
       handoffCount: 0,
+      failedApproaches: [],
       createdAt: new Date().toISOString(),
       updatedAt: new Date().toISOString(),
     },

package/src/server/tools.js

@@ -149,7 +149,7 @@ const SEED_TOOLS = {
         },
       },
     },
-    code: `const toolsFile = path.join(process.env.HOME, '.jarvis/data/tools/tools.json'); const raw = await fs.promises.readFile(toolsFile, 'utf8').catch(() => '{}'); const tools = JSON.parse(raw); tools[args.name] = { definition: { type: 'function', function: { name: args.name, description: args.description, parameters: args.parameters } }, code: args.code }; await fs.promises.writeFile(toolsFile, JSON.stringify(tools, null, 2), 'utf8'); return { status: 'ok', saved: args.name };`,
+    code: `const toolsFile = path.join(process.env.HOME, '.jarvis/data/tools/tools.json'); const raw = await fs.promises.readFile(toolsFile, 'utf8').catch(() => '{}'); const tools = JSON.parse(raw); let parameters = args.parameters; if (typeof parameters === 'string') { try { parameters = JSON.parse(parameters); } catch { return { status: 'error', error: 'parameters must be a JSON Schema object, not a string. Pass the object directly, not as a JSON-serialized string.' }; } } if (typeof parameters !== 'object' || parameters === null || Array.isArray(parameters)) { return { status: 'error', error: 'parameters must be a JSON Schema object (e.g. { type: "object", properties: {...} }).' }; } tools[args.name] = { definition: { type: 'function', function: { name: args.name, description: args.description, parameters } }, code: args.code }; await fs.promises.writeFile(toolsFile, JSON.stringify(tools, null, 2), 'utf8'); return { status: 'ok', saved: args.name };`,
   },
   get_tool: {
     definition: {
@@ -424,7 +424,16 @@ export async function loadTools() {
 }
 
 export function getToolDefinitions(tools) {
-  return Object.values(tools).map(t => t.definition);
+  const defs = [];
+  for (const [name, t] of Object.entries(tools)) {
+    const params = t.definition?.function?.parameters;
+    if (typeof params !== 'object' || params === null || Array.isArray(params)) {
+      console.warn(`[tools] Skipping tool '${name}': parameters is not a valid object (got ${typeof params})`);
+      continue;
+    }
+    defs.push(t.definition);
+  }
+  return defs;
 }
 
 export async function executeTool(tools, name, toolArgs) {