@dimi-agent/cli 0.6.5 → 0.6.7

package/dist/main.mjs

@@ -104346,7 +104346,7 @@ var init_abort = __esmMin((() => {
 //#region ../../packages/agent-core-v2/src/agent/tools/os/bash/bash.md?raw
 var bash_default;
 var init_bash = __esmMin((() => {
-	bash_default = "Execute a `${SHELL_NAME}` command. Use this for shell semantics — pipes, env, processes, git, package managers, build/test runners, anything genuinely interactive or multi-step.\n\n**Translate these to a dedicated tool instead:**\n- `cat` / `head` / `tail` (known path) → `Read`\n- `sed` / `awk` (in-place edit) → `Edit`\n- `echo > file` / `cat <<EOF` → `Write`\n- `find` / recursive `ls` to locate files by name pattern → `Glob` (plain `ls <known-directory>` is fine for listing a directory)\n- `grep` / `rg` (search file contents) → `Grep`\n- `echo` / `printf` (talk to the user) → just output text directly\n\nThe dedicated tools render in the per-tool permission UI and keep raw stdout out of the conversation; that is why they are worth reaching for whenever one fits.\n\n**Output:**\nThe stdout and stderr will be combined and returned as a string. The output may be truncated if it is too long. If the command exits non-zero, the output ends with a `Command failed with exit code: N` line; a command killed by its timeout or interrupted by the user ends with its own message instead.\n\nIf `run_in_background=true`, the command will be started as a background task and this tool will return a task ID instead of waiting for command completion. When doing that, you must provide a short `description`. Background commands default to a ${DEFAULT_BACKGROUND_TIMEOUT_S}s timeout and `timeout` is capped at ${MAX_BACKGROUND_TIMEOUT_S}s; set `disable_timeout=true` only when the task should run without a timeout. You will be automatically notified when the task completes. After starting one, default to returning control to the user instead of immediately waiting on it. Use `TaskOutput` only for a non-blocking status/output snapshot — do not wait on a task you just launched, since its completion arrives automatically. Use `TaskStop` only if the task must be cancelled. If a human user wants to inspect background tasks themselves, point them to the `/tasks` command, which opens an interactive panel; it has no subcommands.\n\n**Guidelines for safety and security:**\n- Each shell tool call will be executed in a fresh shell environment. The shell variables, current working directory changes, and the shell history is not preserved between calls. To run a command in a particular directory, pass the `cwd` argument (or use absolute paths) rather than relying on a `cd` from an earlier call.\n- The tool call will return after the command is finished. You shall not use this tool to execute an interactive command or a command that may run forever. For possibly long-running foreground commands, set the `timeout` argument in seconds. Foreground commands default to ${DEFAULT_TIMEOUT_S}s and allow up to ${MAX_TIMEOUT_S}s. When a foreground command hits its timeout it is moved to the background instead of being killed, and you will be automatically notified when it completes.\n- Avoid using `..` to access files or directories outside of the working directory.\n- Avoid modifying files outside of the working directory unless explicitly instructed to do so.\n- Never run commands that require superuser privileges unless explicitly instructed to do so.\n\n**Guidelines for efficiency:**\n- Use `&&` to chain commands that genuinely depend on each other, e.g. `npm install && npm test`. Independent read-only commands (separate `git show`, `ls`, or status checks) should be issued as separate parallel Bash calls in one response, not chained into a single call — chaining serializes their execution and mixes their output. Do not stitch outputs together with `echo` separators.\n- Use `;` to run commands sequentially regardless of success/failure\n- Use `||` for conditional execution (run second command only if first fails)\n- Use pipe operations (`|`) and redirections (`>`, `>>`) to chain input and output between commands\n- Always quote file paths containing spaces with double quotes (e.g., cd \"/path with spaces/\")\n- Compose multi-step logic in a single call with `if` / `case` / `for` / `while` control flows.\n- Prefer `run_in_background=true` for long-running builds, tests, watchers, or servers when you need the conversation to continue before the command finishes.\n\n**Commands available:**\nThe following common command categories are usually available. Availability still depends on the host, so when in doubt run `which <command>` first to confirm a command exists before relying on it.\n- Navigation and inspection: `ls`, `pwd`, `cd`, `stat`, `file`, `du`, `df`, `tree`\n- File and directory management: `cp`, `mv`, `rm`, `mkdir`, `touch`, `ln`, `chmod`, `chown`\n- Text and data processing: `wc`, `sort`, `uniq`, `cut`, `tr`, `diff`, `xargs`\n- Archives and compression: `tar`, `gzip`, `gunzip`, `zip`, `unzip`\n- Networking and transfer: `curl`, `wget`, `ping`, `ssh`, `scp`\n- Version control: `git`; for GitHub-hosted work (PRs, issues, CI runs, API queries) prefer the `gh` CLI when installed — it carries the user's GitHub auth and can return structured JSON\n- Process and system: `ps`, `kill`, `top`, `env`, `date`, `uname`, `whoami`\n- Language and package toolchains: `node`, `npm`, `pnpm`, `yarn`, `python`, `pip` (use whichever the project actually relies on)\n";
+	bash_default = "Execute a `${SHELL_NAME}` command. Use this for shell semantics — pipes, env, processes, git, package managers, build/test runners, anything genuinely interactive or multi-step.\n\n**Translate these to a dedicated tool instead:**\n- `cat` / `head` / `tail` (known path) → `Read`\n- `sed` / `awk` (in-place edit) → `Edit`\n- `echo > file` / `cat <<EOF` → `Write`\n- `find` / recursive `ls` to locate files by name pattern → `Glob` (plain `ls <known-directory>` is fine for listing a directory)\n- `grep` / `rg` (search file contents) → `Grep`\n- `echo` / `printf` (talk to the user) → just output text directly\n\nThe dedicated tools render in the per-tool permission UI and keep raw stdout out of the conversation; that is why they are worth reaching for whenever one fits.\n\n**Output:**\nThe stdout and stderr will be combined and returned as a string. The output may be truncated if it is too long. If the command exits non-zero, the output ends with a `Command failed with exit code: N` line; a command killed by its timeout or interrupted by the user ends with its own message instead.\n\nIf `run_in_background=true`, the command will be started as a background task and this tool will return a task ID instead of waiting for command completion. When doing that, you must provide a short `description`. Background commands default to a ${DEFAULT_BACKGROUND_TIMEOUT_S}s timeout and `timeout` is capped at ${MAX_BACKGROUND_TIMEOUT_S}s; set `disable_timeout=true` only when the task should run without a timeout. You will be automatically notified when the task completes. After starting one, default to returning control to the user instead of immediately waiting on it. Use `TaskOutput` only for a non-blocking status/output snapshot — do not wait on a task you just launched, since its completion arrives automatically. Use `TaskStop` only if the task must be cancelled. If a human user wants to inspect background tasks themselves, point them to the `/tasks` command, which opens an interactive panel; it has no subcommands.\n\n**Detached processes:** If a command leaves processes running in its process group after the shell exits (e.g. `nohup … &`, `… &`, `disown`), the result includes a notice listing them. Those processes are not tracked by dimi: you will not be notified when they finish, `TaskStop` cannot stop them, and a `WaitFor` only wakes on timeout. If the detach was intentional (e.g. starting a daemon), you may ignore the notice; otherwise prefer `run_in_background=true` so dimi manages the process and notifies you. Note this detection covers processes that stayed in the command's process group; a process that deliberately escapes to its own session (e.g. daemonizers, `setsid`) is not detectable after the command exits and is typically intentional.\n\n**Guidelines for safety and security:**\n- Each shell tool call will be executed in a fresh shell environment. The shell variables, current working directory changes, and the shell history is not preserved between calls. To run a command in a particular directory, pass the `cwd` argument (or use absolute paths) rather than relying on a `cd` from an earlier call.\n- The tool call will return after the command is finished. You shall not use this tool to execute an interactive command or a command that may run forever. For possibly long-running foreground commands, set the `timeout` argument in seconds. Foreground commands default to ${DEFAULT_TIMEOUT_S}s and allow up to ${MAX_TIMEOUT_S}s. When a foreground command hits its timeout it is moved to the background instead of being killed, and you will be automatically notified when it completes.\n- Avoid using `..` to access files or directories outside of the working directory.\n- Avoid modifying files outside of the working directory unless explicitly instructed to do so.\n- Never run commands that require superuser privileges unless explicitly instructed to do so.\n\n**Guidelines for efficiency:**\n- Use `&&` to chain commands that genuinely depend on each other, e.g. `npm install && npm test`. Independent read-only commands (separate `git show`, `ls`, or status checks) should be issued as separate parallel Bash calls in one response, not chained into a single call — chaining serializes their execution and mixes their output. Do not stitch outputs together with `echo` separators.\n- Use `;` to run commands sequentially regardless of success/failure\n- Use `||` for conditional execution (run second command only if first fails)\n- Use pipe operations (`|`) and redirections (`>`, `>>`) to chain input and output between commands\n- Always quote file paths containing spaces with double quotes (e.g., cd \"/path with spaces/\")\n- Compose multi-step logic in a single call with `if` / `case` / `for` / `while` control flows.\n- Prefer `run_in_background=true` for long-running builds, tests, watchers, or servers when you need the conversation to continue before the command finishes.\n\n**Commands available:**\nThe following common command categories are usually available. Availability still depends on the host, so when in doubt run `which <command>` first to confirm a command exists before relying on it.\n- Navigation and inspection: `ls`, `pwd`, `cd`, `stat`, `file`, `du`, `df`, `tree`\n- File and directory management: `cp`, `mv`, `rm`, `mkdir`, `touch`, `ln`, `chmod`, `chown`\n- Text and data processing: `wc`, `sort`, `uniq`, `cut`, `tr`, `diff`, `xargs`\n- Archives and compression: `tar`, `gzip`, `gunzip`, `zip`, `unzip`\n- Networking and transfer: `curl`, `wget`, `ping`, `ssh`, `scp`\n- Version control: `git`; for GitHub-hosted work (PRs, issues, CI runs, API queries) prefer the `gh` CLI when installed — it carries the user's GitHub auth and can return structured JSON\n- Process and system: `ps`, `kill`, `top`, `env`, `date`, `uname`, `whoami`\n- Language and package toolchains: `node`, `npm`, `pnpm`, `yarn`, `python`, `pip` (use whichever the project actually relies on)\n";
 }));
 //#endregion
 //#region ../../packages/agent-core-v2/src/agent/tools/os/bash/process-task.ts
@@ -104571,6 +104571,75 @@ function foregroundDescription(args) {
 	if (explicit !== void 0 && explicit.length > 0) return explicit;
 	return `Bash: ${args.command.length > 60 ? `${args.command.slice(0, 60)}…` : args.command}`;
 }
+/**
+* Detect processes that outlived the command's process group on Unix.
+*
+* dimi spawns every shell in its own session/process group (`setsid`, pid ==
+* sid == pgid), so `nohup`/`&`/`disown` children that survive the shell stay
+* in that same process group. Probing `kill(-pid, 0)` (process-group kill)
+* tells us whether any process is still there after the command finished;
+* `ps -g <pid>` then lists who.
+*
+* Scope: this covers processes that stayed in the command's process group
+* (the common accidental detach: `nohup … &`, `… &`, `disown`). A process
+* that actively escapes (calls `setsid`, or moves to its own group with
+* `setpgid`/`setpgrp`, e.g. daemonizers, `start_new_session=True`, node
+* `{detached:true}`) leaves the group entirely and cannot be attributed back
+* after the shell exits — such escapes are typically intentional and are out
+* of scope here. Windows has no session/process-group kill, so detection is
+* skipped there (returns []).
+*/
+async function detectDetachedProcesses(pid) {
+	if (process.platform === "win32" || !Number.isInteger(pid) || pid <= 0) return [];
+	let alive = false;
+	try {
+		process.kill(-pid, 0);
+		alive = true;
+	} catch (error) {
+		alive = error.code === "EPERM";
+	}
+	if (!alive) return [];
+	return listProcessGroupProcesses(pid);
+}
+async function listProcessGroupProcesses(pid) {
+	const { execFile } = await import("node:child_process");
+	const ps = await new Promise((resolve) => {
+		execFile("ps", [
+			"-o",
+			"pid=,ppid=,command=",
+			"-g",
+			String(pid)
+		], (error, stdout) => {
+			resolve(error === null ? stdout : "");
+		});
+	});
+	const infos = [];
+	for (const line of ps.split("\n")) {
+		const trimmed = line.trim();
+		if (trimmed.length === 0) continue;
+		const match = /^(\d+)\s+(\d+)\s+(.*)$/.exec(trimmed);
+		if (match === null) continue;
+		const childPid = Number(match[1]);
+		if (childPid === pid) continue;
+		infos.push({
+			pid: childPid,
+			ppid: Number(match[2]),
+			command: match[3] ?? ""
+		});
+	}
+	return infos;
+}
+/**
+* Rendered guidance appended to a Bash result when the finished command left
+* detached processes behind. Informational only — the command result itself
+* is unchanged; the agent decides whether the detach was intended.
+*/
+function formatDetachedProcessNotice(infos) {
+	return `
+
+⚠ Command left processes running outside dimi control:
+${infos.map((info) => `  - pid ${String(info.pid)} (ppid ${String(info.ppid)}): ${info.command}`).join("\n")}\nThese processes are NOT tracked by dimi: dimi cannot notify you when they finish, cannot stop them with TaskStop, and a WaitFor will only wake on timeout. If this was intentional (e.g. starting a daemon), ignore this notice. Otherwise, prefer running the command with run_in_background=true so dimi manages it.`;
+}
 async function killSpawnedProcess(proc) {
 	try {
 		await proc.kill("SIGTERM");
@@ -104581,6 +104650,15 @@ async function killSpawnedProcess(proc) {
 function shellQuote(s) {
 	return `'${s.replaceAll("'", "'\\''")}'`;
 }
+function partToResultText(part) {
+	switch (part.type) {
+		case "text": return part.text;
+		case "think": return part.think;
+		case "image_url": return "[image]";
+		case "audio_url": return "[audio]";
+		case "video_url": return "[video]";
+	}
+}
 function windowsPathToPosixPath(path) {
 	if (path.startsWith("\\\\")) return path.replaceAll("\\", "/");
 	const driveMatch = /^([A-Za-z]):(?:[\\/]|$)/.exec(path);
@@ -104819,7 +104897,31 @@ var init_bashTool = __esmMin((() => {
 				if (builder.nChars === 0) builder.write(`Process exited with code ${String(exitCode)}`);
 				result = builder.error(`Command failed with exit code: ${String(exitCode)}.`, { brief: `Failed with exit code: ${String(exitCode)}` });
 			}
-			return this.addForegroundOutputReference(taskId, result);
+			const withReference = await this.addForegroundOutputReference(taskId, result);
+			return this.addDetachedProcessNotice(proc, withReference);
+		}
+		/**
+		* After a foreground command finishes, check whether it left processes
+		* running in the command's process group (e.g. `nohup … &`) that dimi can
+		* no longer track. When it did, append an informational notice to the
+		* result — the exit code / error status is untouched, and the agent
+		* decides whether the detach was intended. Processes that actively escape
+		* to their own session/group (setsid, daemonizers) cannot be detected
+		* after the shell exits and are out of scope.
+		*/
+		async addDetachedProcessNotice(proc, result) {
+			const infos = await this.detectDetached(proc.pid);
+			if (infos.length === 0) return result;
+			const output = result.output;
+			const text = typeof output === "string" ? output : output.map(partToResultText).join("");
+			return {
+				...result,
+				output: `${text}${formatDetachedProcessNotice(infos)}`
+			};
+		}
+		/** Overridable seam for tests: probe for processes that escaped the session. */
+		detectDetached(pid) {
+			return detectDetachedProcesses(pid);
 		}
 		async addForegroundOutputReference(taskId, result) {
 			if (!result.truncated) return result;
@@ -123100,7 +123202,7 @@ var init_waitService = __esmMin((() => {
 //#region ../../packages/agent-core-v2/src/agent/tools/wait-for/wait-for.md?raw
 var wait_for_default;
 var init_wait_for = __esmMin((() => {
-	wait_for_default = "Wait for a future notification when no independent work remains. Provide a concise reason and an optional timeout in seconds. The default is 60 seconds; use longer waits only for clearly long-running work, up to 1800 seconds.\n\nCall WaitFor by itself. It waits on the current agent, not a specific task. Any later notification wakes the agent. A timeout wakes the agent with an explicit `wait_expired` message and never cancels background work.\n\nWhen you are waiting on an external state that can change on its own (a file being written, a service coming up, a process finishing, a remote resource becoming ready, …), do not just park on a timeout and re-check later. Start a background Bash task that polls exactly the part of that state you care about and exits as soon as it changes — for example a loop that checks every few seconds and breaks on the expected condition, printing what changed. Because a finished background task notifies the agent, the wait then wakes you the moment the state flips instead of on a blind timeout, and you can act immediately. Keep the polling script narrowly scoped to the monitored condition and make sure it terminates on its own (or after the wait timeout); do not leave a watcher running forever.\n\nSurface errors from the watcher loudly instead of hiding them. If a check fails, a command errors, or the target becomes unreachable, print the error and exit with a non-zero code so the failed background task wakes you with the real reason — then you can diagnose and retry immediately. Do not swallow failures with `|| true`, `2>/dev/null`, or a `continue` that keeps polling forever; a watcher that silently runs to timeout hides the very condition you are waiting on.\n\n";
+	wait_for_default = "Wait for a future notification when no independent work remains. Provide a concise reason and an optional timeout in seconds. The default is 60 seconds; use longer waits only for clearly long-running work, up to 1800 seconds.\n\nCall WaitFor by itself. It waits on the current agent, not a specific task. Any later notification wakes the agent. A timeout wakes the agent with an explicit `wait_expired` message and never cancels background work.\n\nWhen you are waiting on an external state that can change on its own (a file being written, a service coming up, a process finishing, a remote resource becoming ready, …), do not just park on a timeout and re-check later. Start a background Bash task that polls exactly the part of that state you care about and exits as soon as it changes — for example a loop that checks every few seconds and breaks on the expected condition, printing what changed. Because a finished background task notifies the agent, the wait then wakes you the moment the state flips instead of on a blind timeout, and you can act immediately. Keep the polling script narrowly scoped to the monitored condition and make sure it terminates on its own (or after the wait timeout); do not leave a watcher running forever.\n\nStart the watcher as a dimi background task with `run_in_background=true` on the Bash tool — never launch it detached from the session (no `nohup`, no `&` outside the tool, no cron or external scheduler). Only a dimi background task is tracked by the agent runtime, so only its completion (success or failure) can wake the wait; a detached process is invisible to dimi, gives no notification, and leaves you sleeping until the timeout. The watcher must exit on its own when the state flips or the wait deadline passes.\n\nSurface errors from the watcher loudly instead of hiding them. If a check fails, a command errors, or the target becomes unreachable, print the error and exit with a non-zero code so the failed background task wakes you with the real reason — then you can diagnose and retry immediately. Do not swallow failures with `|| true`, `2>/dev/null`, or a `continue` that keeps polling forever; a watcher that silently runs to timeout hides the very condition you are waiting on.\n\n\n";
 }));
 //#endregion
 //#region ../../packages/agent-core-v2/src/agent/tools/wait-for/waitForTool.ts

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dimi-agent/cli",
-  "version": "0.6.5",
+  "version": "0.6.7",
   "description": "The Starting Point for Next-Gen Agents",
   "keywords": [
     "agent",
@@ -61,13 +61,13 @@
     "yazl": "^3.3.1",
     "zod": "^4.3.6",
     "@dimi-agent/agent-core-v2": "^0.1.0",
-    "@dimi-agent/dimi-oauth": "^0.1.0",
     "@dimi-agent/dimi-sdk": "^0.2.0",
+    "@dimi-agent/dimi-oauth": "^0.1.0",
     "@dimi-agent/dimi-telemetry": "^0.1.0",
     "@dimi-agent/dimi-web": "^0.1.0",
-    "@dimi-agent/kap-server": "^0.1.0",
     "@dimi-agent/pi-tui": "^0.1.0",
-    "@dimi-agent/remote": "^0.1.0"
+    "@dimi-agent/remote": "^0.1.0",
+    "@dimi-agent/kap-server": "^0.1.0"
   },
   "optionalDependencies": {
     "@dimi-agent/dimi-native-darwin-arm64": ">=0.5.3 <1",