@pify/shell-background 0.4.0 → 0.4.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -34,7 +34,7 @@ shell_kill { id: "bg-2" } # stop it and its whole process tree
34
34
 
35
35
  ## Delivery, and the headless caveat
36
36
 
37
- When a backgrounded command finishes in an **interactive** session, its result is pushed into the conversation as the next turn — you do not have to poll. Under headless `pi -p` there is nothing to deliver into (the session tears down when the prompt resolves), so **auto-background is disabled there** and only explicit `background: true` applies; collect it within the same turn with `shell_status { id, wait: N }`, which blocks (up to `N` seconds, 0–300) until the command finishes rather than returning immediately. This is the same delivery rule the rest of the suite lives by.
37
+ When a backgrounded command finishes in an **interactive** session, its result is pushed into the conversation as the next turn — you do not have to poll. Under headless `pi -p` there is nothing to deliver into (the session tears down when the prompt resolves), so **auto-background is disabled there** and only explicit `background: true` applies; collect it within the same turn with `shell_status { id, wait: N }`, which blocks (up to `N` seconds, 0–300) until the command finishes rather than returning immediately. This is the same delivery rule the rest of the suite lives by. A finish that a `shell_status` wait returns is collected there and not delivered a second time, so the model never spends a turn acknowledging a result it has just reported.
38
38
 
39
39
  ## How it works
40
40
 
@@ -229,6 +229,18 @@ export default function shellBackground(pi: ExtensionAPI) {
229
229
  );
230
230
  }
231
231
 
232
+ /**
233
+ * Jobs a shell_status wait is blocking on, by id. Seen on pi 1.0.4 with the
234
+ * TUI captured: a foreground command auto-backgrounds at 30s, the model
235
+ * waits on it with shell_status, the exit handler delivers the finish as a
236
+ * follow-up in the same instant the wait returns it, and the model spends a
237
+ * whole extra turn acknowledging a result it had just reported. While a
238
+ * wait is active the finish is returned there and marked collected; the
239
+ * delivery path stands down.
240
+ */
241
+ const waiters = new Map<string, number>();
242
+ const awaited = (job: Job): boolean => (waiters.get(job.id) ?? 0) > 0;
243
+
232
244
  /** Deliver a finished background job into the conversation, once. */
233
245
  function scheduleDelivery(job: Job, exit: Promise<unknown>): void {
234
246
  exit
@@ -241,7 +253,7 @@ export default function shellBackground(pi: ExtensionAPI) {
241
253
  registry?.persist(job);
242
254
  return;
243
255
  }
244
- if (job.delivered) return;
256
+ if (job.delivered || awaited(job)) return;
245
257
  job.delivered = true;
246
258
  registry?.persist(job);
247
259
  deliver(job);
@@ -522,7 +534,22 @@ export default function shellBackground(pi: ExtensionAPI) {
522
534
  const waitSec = Number.isFinite(params.wait) ? Math.min(300, Math.max(0, Math.floor(params.wait as number))) : 0;
523
535
  if (waitSec > 0 && job.status === "running") {
524
536
  const deadline = Date.now() + waitSec * 1000;
525
- while (job.status === "running" && Date.now() < deadline && !sig?.aborted) await sleep(250);
537
+ waiters.set(job.id, (waiters.get(job.id) ?? 0) + 1);
538
+ try {
539
+ while (job.status === "running" && Date.now() < deadline && !sig?.aborted) await sleep(250);
540
+ } finally {
541
+ waiters.set(job.id, Math.max(0, (waiters.get(job.id) ?? 1) - 1));
542
+ }
543
+ }
544
+ if (sig?.aborted) {
545
+ // The model never sees an aborted tool result. If the job finished
546
+ // while this wait held the delivery path back, deliver it now.
547
+ if (isFinished(job) && !job.delivered) {
548
+ job.delivered = true;
549
+ registry.persist(job);
550
+ deliver(job);
551
+ }
552
+ return { content: [{ type: "text", text: `shell_status ${job.id}: wait aborted` }], details: { id: job.id }, isError: true };
526
553
  }
527
554
  // Reading a finished job marks it collected so it will not also be
528
555
  // delivered unasked. A still-running poll must never do this: setting
@@ -614,7 +641,7 @@ export default function shellBackground(pi: ExtensionAPI) {
614
641
  }
615
642
  }
616
643
  if (job.status === "running") anyRunning = true;
617
- else if (!job.delivered) {
644
+ else if (!job.delivered && !awaited(job)) {
618
645
  job.delivered = true;
619
646
  registry.persist(job);
620
647
  deliver(job);
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@pify/shell-background",
3
- "version": "0.4.0",
3
+ "version": "0.4.2",
4
4
  "description": "Long-running bash goes async: background: true launches detached, and any command still running after 30s auto-backgrounds and delivers its result when it finishes",
5
5
  "keywords": [
6
6
  "pi-package",
package/src/format.ts CHANGED
@@ -17,12 +17,11 @@ function duration(job: Job): string {
17
17
  return secs(Math.max(0, end - job.startedAt));
18
18
  }
19
19
 
20
- /** `[bg-1 · done · exit 0 · 4.2s]` — the one-line header every result carries. */
20
+ /** `[bg-1 · done · exit 0 · 4.2s]` — the one-line header every result carries. A running job has no verdict yet: `[bg-1 · running · 13.2s]`. */
21
21
  export function header(job: Job): string {
22
+ if (job.status === "running") return `[${job.id} · running · ${duration(job)}]`;
22
23
  const verdict =
23
- job.status === "running"
24
- ? "running"
25
- : job.status === "orphaned"
24
+ job.status === "orphaned"
26
25
  ? "orphaned (another session)"
27
26
  : job.signal
28
27
  ? `signal ${job.signal}`
package/src/registry.ts CHANGED
@@ -44,7 +44,8 @@ export class JobRegistry {
44
44
 
45
45
  constructor(baseDir: string) {
46
46
  this.baseDir = baseDir;
47
- mkdirSync(join(baseDir, "logs"), { recursive: true });
47
+ // Logs and sidecars carry command output and cwd paths: the user's eyes only.
48
+ mkdirSync(join(baseDir, "logs"), { recursive: true, mode: 0o700 });
48
49
  }
49
50
 
50
51
  /** The directory this registry's sidecars and logs live under. */
@@ -93,7 +94,7 @@ export class JobRegistry {
93
94
  try {
94
95
  const file = join(this.baseDir, `${job.id}.json`);
95
96
  const tmp = `${file}.${process.pid}.tmp`;
96
- writeFileSync(tmp, JSON.stringify(job));
97
+ writeFileSync(tmp, JSON.stringify(job), { mode: 0o600 });
97
98
  renameSync(tmp, file);
98
99
  } catch {
99
100
  // A registry we cannot persist still works for the live session.
package/src/spawn.ts CHANGED
@@ -40,7 +40,9 @@ export function spawnToFile(
40
40
  logPath: string,
41
41
  ): Spawned {
42
42
  // Append so a re-attach or racing read never clips output already written.
43
- const out = createWriteStream(logPath, { flags: "a" });
43
+ // Command output can carry private data, so the log is readable by the user
44
+ // only (pi 1.0.3 does the same for its own output files; a no-op on Windows).
45
+ const out = createWriteStream(logPath, { flags: "a", mode: 0o600 });
44
46
  // A write stream with no 'error' listener turns any disk error (ENOSPC,
45
47
  // EACCES) or a stray write-after-end into an uncaught exception that takes the
46
48
  // whole pi host down. Losing a log line is survivable; crashing the host is