Enforce session ownership when polling tasks

When multiple sessions share the same servicer process, spawn records session_key on the ShellTask, but these poll/kill branches dispatch only the caller-supplied task_id and never compare it with start.session_key. If a task id is copied or leaked between conversations, another session can read that task's shell output or terminate its process, so the new per-session tagging does not actually isolate background tasks; pass the caller session through and reject mismatches.

Useful? React with 👍 / 👎.

Cap background task log growth

For a background command that emits unbounded output, this pump writes every chunk to the workspace log without any size cap or truncation. The child RLIMIT_FSIZE does not protect this file because the parent process is doing the write, and the default watchdog allows the task to run for up to 30 minutes, so a single noisy task can fill the workspace or host disk; enforce a maximum log size or stop/truncate the task when the spill file grows too large.

Useful? React with 👍 / 👎.

Kill the child when spill setup fails

If the workspace log cannot be opened here (for example .corlinman is a file or the directory is not writable), _pump catches the exception and marks the task failed without killing or waiting for task._proc. A silent long-running command such as sleep 9999 would then continue outside the concurrency cap, and later shell_task_kill returns early because the task is already terminal; kill the process group before retiring a pump-failed task.

Useful? React with 👍 / 👎.

Add shell_task_kill to mutating permissions

This new termination branch is reachable after the permission gate, but the gate's MUTATING_TOOLS set in permission.py only includes run_shell and not shell_task_kill. In plan mode or strict mode, a model can still kill an already-running background process even though those modes deny other side-effecting tools, so classify the new kill tool as mutating before dispatching it.

Useful? React with 👍 / 👎.

Reject empty-session polling of owned tasks

When a tool call reaches the servicer with start.session_key == "" (the gateway still normalizes requests with no session key to an empty string), expected_session_key is falsy here and the ownership check is skipped. That lets a no-session caller with a known/leaked task_id read output from a task spawned under a non-empty session; the same guard is repeated in kill(), so termination has the same bypass. Fresh evidence beyond the prior ownership comment is that the new registry explicitly treats an empty expected key as a bypass while production callers can still be empty-session.

Useful? React with 👍 / 👎.

Bound shell task output responses

When a chatty background task reaches the default 16 MiB log cap and the model polls from offset=0, this puts the entire unread log into one tool result. The servicer journals result_json verbatim before the reasoning-loop spill/truncation path, so a single poll can push a multi-megabyte gRPC/tool-result payload and database row; foreground run_shell avoids this with a 16k inline cap, so shell_task_output should page or cap each response while still advancing new_offset.

Useful? React with 👍 / 👎.

Reap process group before marking shell tasks complete

For commands that explicitly daemonize/background their real work and close the inherited pipe, such as sleep 600 >/dev/null 2>&1 &, the shell exits with code 0 and this path marks the task completed even though a child in the same process group is still running. Once the row is terminal, the lifetime watchdog and later shell_task_kill will not reap that process, so these commands escape the new concurrency/lifetime controls; check for or kill the remaining process group before retiring the task.

Useful? React with 👍 / 👎.

Require a real boolean for background mode

With providers or direct clients that do not strictly enforce the tool schema, run_in_background can arrive as the string "false" or another truthy non-boolean value. This truthiness check then takes the background path and returns only a task_id/status instead of the foreground output and exit code the caller requested; the nearby subagent parser already rejects non-boolean run_in_background, so this should either branch only on is True or return args_invalid for non-bool values before spawning.

Useful? React with 👍 / 👎.

Clamp oversized shell-task offsets

If a model or client sends an offset larger than the platform file-offset type, this seek() raises ValueError instead of OSError, so the new shell_task_output path escapes the dispatcher’s never-raise envelope and the servicer reports a generic builtin_tool_failed for a bad paging argument. Clamp or reject excessively large offsets before seeking, or catch ValueError here and return an args_invalid/safe empty read response.

Useful? React with 👍 / 👎.

Reap orphaned writers when the log cap trips

When a command backgrounds a chatty child and the shell wrapper exits before the log cap trips, kill_process_group(proc) can no longer resolve the wrapper pid's process group and falls back to killing only the already-dead wrapper. This capped branch then marks the task terminal and returns before the natural-exit reap_orphan_group(proc) below can run, so that writer can survive or block outside the watchdog and later shell_task_kill is a no-op; use the same direct pgid reap here before retiring the task.

Useful? React with 👍 / 👎.

Reap orphaned process groups during shutdown

When shutdown runs after a task whose shell wrapper has already exited but a background child still holds the stdout pipe open (for example sleep 600 &), kill_process_group() can no longer resolve the wrapper pid's process group and only falls back to killing the dead wrapper. The task is then marked terminal and shutdown() awaits the pump, which remains blocked on the still-open pipe until the child exits naturally; use the same _reap() path used by kill/watchdog/natural-exit before retiring shutdown tasks.

Useful? React with 👍 / 👎.

Catch OverflowError while parsing shell-task offsets

If a client sends an offset as a JSON number that Python parses as a non-finite float, such as 1e10000, int(offset) raises OverflowError, which is not caught here; the dispatcher then escapes its JSON-envelope contract and the servicer reports a generic builtin_tool_failed for a bad paging argument. Fresh evidence beyond the prior oversized-offset comment is that this exception occurs before ShellTaskRegistry.read(), so the new seek-side OverflowError catch does not cover it.

Useful? React with 👍 / 👎.

Extend subagent run_shell allowlists to task tools

When a subagent is spawned with a narrow tool_allowlist or card allowance containing only shell.run/run_shell, the unchanged subagent runner still filters that to just run_shell and rejects later shell_task_output/shell_task_kill as outside allowed_tools. Fresh evidence beyond the prior skill-allowlist comment is that only _skill_allowed_tools_block got the run_shell⇒task-tools implication, so this schema can hand narrowed subagents a background task_id they are forbidden to poll or terminate.

Useful? React with 👍 / 👎.

Reap orphaned groups in the atexit path

For a background task such as sleep 600 &, the shell wrapper can exit while the child keeps the stdout pipe open, leaving the task running until shutdown. In this atexit-only path, kill_process_group() cannot resolve the process group from the already-exited wrapper PID and falls back to killing only that dead wrapper, so the child can survive interpreter exit; use the same _reap/reap_orphan_group logic used by the async shutdown paths before returning.

Useful? React with 👍 / 👎.

Allow task kills with explicit run_shell grants

In strict or plan mode, an explicit permission rule can allow run_shell, but this separate mutating entry means the follow-up shell_task_kill still falls through to the mode/strict default and is denied. Because the run_shell schema now tells models to use run_in_background=true, that configuration can start a long-running background task but cannot terminate it except by waiting for the watchdog; mirror the run_shell ⇒ task-tool implication used by the skill/subagent allowlists or require the spawn path to reject background mode when kill is not permitted.

Useful? React with 👍 / 👎.

Bind child background shells to subagent lifetimes

When this branch is reached from the subagent child executor, start is the parent's ChatStart, so a child run_shell(run_in_background=true) is registered under the parent session and returns immediately. If that child then hits max_wall_seconds or is cancelled, the subagent runner has no record to clean up and the process can keep running until the global shell-task watchdog, bypassing the child wall-clock cap; track/reap background tasks per child or reject background shell mode inside child execution.

Useful? React with 👍 / 👎.

Honor arg-scoped shell grants for task kills

When strict/plan deployments allow only specific shell commands, e.g. run_shell(npm:*), a background call that matches the command rule can still start, but shell_task_kill is re-evaluated as run_shell against kill args that contain only task_id, so extract_arg_candidates("run_shell", args) returns no command and the arg-scoped allow never matches. This is separate from the prior broad-allow case: the new alias fixes tool="run_shell" rules, but arg-scoped grants can still create a background task that the model cannot terminate until the watchdog expires.

Useful? React with 👍 / 👎.

Fixed in b4e1ed3. Root cause was that the argless kill call carries no command, so the scoped run_shell(npm:*) pattern can never match it. New _can_start_shell_tasks(ctx) mirrors the resolver's rule/mode/strict/default ordering but honours ANY run_shell allow (scoped or unscoped), ignoring arg scope — a scoped grant proves the session can start that command's task, so it may control it. shell_task_kill denied only by strict/default is now rescued when the session can start tasks. Confined by the registry's session-ownership gate. New test test_task_control_honours_arg_scoped_run_shell_grant.

Avoid granting task controls to foreground-only children

When a child is given a narrow run_shell allowance, this still advertises shell_task_output and shell_task_kill, but _make_child_tool_executor now rejects run_in_background=true for children, so the child cannot legitimately create a background task of its own. Because child tool calls are dispatched with the parent start.session_key, a child that receives or is prompted with a parent task id can poll or kill the parent's background job despite only being granted run_shell; drop this implication for subagents while background shell mode is refused there.

Useful? React with 👍 / 👎.

Fixed in b4e1ed3. Dropped the run_shell⇒{output,kill} implication for children entirely: a child is refused run_in_background (can't make a bg task) and dispatches tool calls under the PARENT session_key, so implying the controls let any child with plain run_shell reach the parent's jobs. A child now only gets a control tool if its allowlist names it explicitly. Inverted test_subagent_run_shell_does_not_imply_task_tools + added test_subagent_task_tools_only_when_explicitly_requested.

Let shell polling inherit run_shell allow rules

In allowlist-style permission configs, e.g. [{"tool":"run_shell","action":"allow"},{"tool":"*","action":"deny"}], run_shell(run_in_background=true) is permitted and returns a task_id, but the required follow-up shell_task_output call is not aliased here and falls through to the wildcard deny. The kill tool inherits the run_shell grant, but polling remains blocked, so either make shell_task_output inherit the same grant or reject background mode when the caller will not be allowed to poll it.

Useful? React with 👍 / 👎.

Fixed in b4e1ed3. shell_task_output now participates in the same grant-tracking rescue as shell_task_kill: a control tool denied ONLY by a wildcard (*) rule is the catch-all-swallow case and is rescued iff _can_start_shell_tasks(ctx) — so [run_shell allow, * deny] lets the model poll the task it was allowed to start. Kept output UN-aliased so it stays read-only-allowed in plan mode (the round-1 contract). New test test_task_control_rescued_from_wildcard_deny; test_task_control_denied_when_run_shell_denied proves it's grant-tracking, not a blanket allow.

Drop task controls from inherited child tool sets

Fresh evidence beyond the earlier narrow-allowlist concern is that the default/wildcard inherit path still copies the parent's whole tool set before this note, and the parent set now always includes shell_task_output/shell_task_kill. For a general-purpose child with tools_allowed=["*"] and no tool_allowlist, those controls are still advertised even though the child cannot create background tasks and its tool calls run under the parent session key, so a child given a parent task_id can poll or kill the parent's job without an explicit task-control grant.

Useful? React with 👍 / 👎.

Fixed in ec93be8. Correct — r7 only removed the implication; the wildcard/legacy-card inherit path (tools_allowed=["*"] or empty card → effective = set(parent)) still copied the controls wholesale. Child filtering now ACTIVELY strips shell_task_output/shell_task_kill for every child (child_depth>=1) unless the per-spawn allowlist NAMES them — covers both the inherit path and the narrow-allowlist path. New test test_subagent_wildcard_child_strips_task_controls (legacy card + explicit ["*"]), and test_subagent_task_tools_only_when_explicitly_requested confirms an explicit request still grants.

Treat ask rules as shell-task start grants

With a permission setup such as run_shell set to ask plus default_action=deny or a * deny catch-all, an approved run_shell(run_in_background=true) can start and return a task_id, but _can_start_shell_tasks() returns false because ASK is not considered a start capability here. The task-control rescue therefore does not apply, leaving shell_task_output denied (and scoped-ask kills denied) for a task the user just approved; include ASK in this predicate or otherwise carry the approval through to task controls.

Useful? React with 👍 / 👎.

Fixed in ec93be8. ASK now counts as a start capability in _can_start_shell_tasks. Behaviour: read-only shell_task_output is rescued to allow (never left denied by the catch-all); a scoped-ask kill is rescued to allow (the argless call can't be tied to the scoped command, and the task was already approved at start); a broad run_shell=ask kill inherits ask via the alias (prompt-before-kill, consistent with an ask-before-shell policy). Nothing stays denied. New test test_task_control_carries_ask_approval_through.

Re-check child background mode after hook mutations

Fresh evidence beyond the earlier child-lifetime issue is that this guard runs before _dispatch_builtin, but builtin pre-tool hooks later may replace event.args_json with mutated_args before the final dispatch. If a hook normalizes or rewrites a child run_shell call to add run_in_background=true, this check has already passed and the task is spawned under the parent session, again escaping the child's wall-clock/cancel lifecycle; enforce the child background ban after hook mutation or in the dispatch path with child context.

Useful? React with 👍 / 👎.

Wait for the pump before publishing killed state

When shell_task_kill is called while the pump still has buffered pipe data to append, this marks the task terminal before the pump has finished draining and writing the log. A caller that kills and then immediately polls can observe status: killed with has_more: false at the current EOF, then stop polling even though the pump may append the final output moments later; wait for the pump (or otherwise delay the terminal stamp) so a terminal status means the spill file is complete.

Useful? React with 👍 / 👎.

Honor explicit shell_task_kill permission rules

When a deployment adds an explicit shell_task_kill rule, this alias rewrites the tool to run_shell before rule matching, so the kill-specific rule is never considered. For example, in strict mode [{"tool":"shell_task_kill","action":"allow"}] still denies kills, and [{"tool":"shell_task_kill","action":"deny"},{"tool":"run_shell","action":"allow"}] still allows them; check rules for the real control tool before falling back to run_shell inheritance.

Useful? React with 👍 / 👎.

Hide background shell mode from child schemas

When run_shell is granted to a subagent, the runner projects the parent's tool schema unchanged, but the child executor rejects run_in_background=true with background_not_allowed_in_subagent. In that context this description tells the child to use a mode it cannot execute (and often cannot poll/kill), so long-running child tasks such as dev servers or watchers are likely to fail immediately; strip this property/wording from child-projected schemas or make the child executor actually own background tasks.

Useful? React with 👍 / 👎.

Wire shell-task shutdown into server close

This process-wide registry now owns long-running child processes, but I found no caller for ShellTaskRegistry.shutdown() in the server lifecycle (CorlinmanAgentServicer.aclose only closes journal/memory/blackboard/persona/hook resources). In a graceful stop or hot reload where the Python process continues, a task spawned via run_shell(run_in_background=true) keeps running until the watchdog with no live RPC surface left to poll or kill it; call this shutdown hook from the servicer/gateway close path.

Useful? React with 👍 / 👎.

Carry default ask approvals into task polling

With default_action=ask and no explicit run_shell rule, an approved run_shell(run_in_background=true) can start a task, but shell_task_output has no matching rule and falls through to this default ASK on every poll. Because polling is the only way to observe completion/output, that setup forces repeated human approvals for each output page (or strands the task if a poll is denied); treat the default ask start capability like the explicit ask-rule path and allow read-only polling for the approved task.

Useful? React with 👍 / 👎.