offloader-target

name	offloader-target
description	Use this to inspect long-running tasks the user dispatched to this machine through Offloader. This is relevant when the user asks about dispatched task status, dispatched task logs or output, whether a related command is still alive, or what branch/worktree a dispatched run used.

Offloader Target Task State

You are on the machine where the dispatched command runs. Inspect local files and processes directly, then answer with the concrete state you found.

Offloader launches a command on this machine using a normal checkout with linked worktrees. The source branch is pushed first, then the run branch is pushed as:

offloader/<run-id>

Default target paths are:

~/.remote-work/repos/<repo-path>
~/.remote-work/repos/<repo-path>/.worktrees/offloader-<run-id>

Useful environment names: OFFLOADER_REPO_PATH, OFFLOADER_REMOTE_ROOT, OFFLOADER_WORKTREE_DIR, OFFLOADER_RUN_BRANCH.

Inspect Local State

List recent Offloader worktrees under the remote root:

set -o pipefail
root="${OFFLOADER_REMOTE_ROOT:-${HOME}/.remote-work}"
find "${root}/repos" -type d -path '*/.worktrees/*' -prune -print 2>/dev/null \
  | while IFS= read -r worktree_path; do
      if modified=$(stat -c '%Y' "${worktree_path}" 2>/dev/null); then
        :
      else
        modified=$(stat -f '%m' "${worktree_path}")
      fi
      printf '%s %s\n' "${modified}" "${worktree_path}"
    done \
  | sort -nr \
  | head -n 20

Inspect the selected worktree:

worktree="${HOME}/.remote-work/repos/gh/OWNER/REPO/.worktrees/offloader-run-id"
git -C "${worktree}" status --short --branch
git -C "${worktree}" log -1 --oneline

Check recent file activity in a selected worktree:

: "${worktree:?set worktree first}"
set -o pipefail
find "${worktree}" -xdev -type f -print 2>/dev/null \
  | while IFS= read -r path; do
      if modified=$(stat -c '%Y' "${path}" 2>/dev/null); then
        :
      else
        modified=$(stat -f '%m' "${path}")
      fi
      printf '%s %s\n' "${modified}" "${path}"
    done \
  | sort -nr \
  | head -n 40

Look for a process tied to that worktree:

: "${worktree:?set worktree first}"
pgrep -fl "${worktree}" || true

Local Branch Clues

When working locally in the source repo, these commands often identify the Offloader run branch or pushed state:

git branch --list 'offloader/*'
git log --all --decorate --oneline --grep='Worktree State: status=' -20
git remote -v

Offloader itself runs commands like:

offloader -- npm run dev
offloader --command 'npm run test'

Offloader writes the pushed repo state to a local worktree on this machine and runs the requested command there. Detached runs leave their output at <worktree>.log, and open-ended ones also leave <worktree>.run.sh (what was launched). The dispatch command returns an early launch failure directly; it does not leave a separate status artifact. Attached runs leave no log file of their own; for those, say so and report process state, worktree status, last commit, and recent file activity instead.

Open-Ended Harness Runs

Open-ended dispatches run a coding harness in the worktree, using claude -p "/goal ..." or a small codex app-server driver, wrapped so worktree state is committed and pushed when the run ends. They are detached with setsid, or nohup where setsid is unavailable, so expect no parent session. Read progress and the launched script directly:

worktree="${HOME}/.remote-work/repos/gh/OWNER/REPO/.worktrees/offloader-run-id"
tail -n 50 "${worktree}.log"
cat "${worktree}.run.sh"

Check whether a run is still alive:

pgrep -fl 'claude|codex' || true

Several runs can be live at once, and the command line rarely names the worktree. Attribute a harness process to a specific run by its working directory (on macOS targets, which have no /proc, use lsof -a -p "${pid}" -d cwd in place of the readlink):

: "${worktree:?set worktree first}"
set -o pipefail
process_cwd() {
  local pid="${1}"
  if [[ -e "/proc/${pid}/cwd" ]]; then
    readlink "/proc/${pid}/cwd"
  elif command -v lsof >/dev/null 2>&1; then
    lsof -a -p "${pid}" -d cwd -Fn 2>/dev/null | awk 'substr($0, 1, 1) == "n" { print substr($0, 2); exit }'
  fi
}
while IFS= read -r pid; do
  cwd=$(process_cwd "${pid}") || cwd=""
  case "${cwd}" in
    "${worktree}"|"${worktree}"/*) ps -o pid,etime,command -p "${pid}" ;;
    *) : ;;
  esac
done < <(pgrep -f 'claude|codex' || true)

The wrapper's completion signal is a commit whose subject matches:

Offload Run Worktree State: status=<status>

status=complete means the harness finished its goal; status=failed means it exited early and the commit holds partial work. Older runs used the subject prefix Codex Goal Worktree State. Find the latest outcome with:

: "${worktree:?set worktree first}"
git -C "${worktree}" log --decorate --oneline --grep='Worktree State: status=' -20
git -C "${worktree}" log -1 --format=fuller

Harness runs track state through git commits, the run log, and live processes — no pidfiles or status files. Report what those signals show.