@andrian.yablonskyy/thub-agent 1.1.3 → 1.1.4

package/README.md

@@ -9,12 +9,12 @@ See the [main TestHub repo](https://github.com/andrianyablonskyy/thub) for the f
 ```bash
 npm i -g @andrian.yablonskyy/thub-agent
 # or, one-off in CI:
-npx -y @andrian.yablonskyy/thub-agent run --type sw --download-file "$IMAGE_URL" --git-repo "$TESTS_REPO" --command ./ci/test.sh --wait
+npx -y @andrian.yablonskyy/thub-agent run --type sw --download-file "$IMAGE_URL" --command ./ci/test.sh --wait
 ```
 
 ## Configuration
 
-Read from flags (`--url`, `--key`), then environment (`THUB_URL`, `THUB_KEY`, `THUB_USER`; the old names `--token`/`THUB_TOKEN` still work), then `~/.config/thub/agent.json`, then a bundled default. `url`/`token` are required by the time a command actually talks to the Coordinator; `group`/`user` are optional everywhere.
+Read from flags (`--url`, `--key`), then environment (`THUB_URL`, `THUB_KEY`; the old names `--token`/`THUB_TOKEN` still work), then `~/.config/thub/agent.json`, then a bundled default. `url`/`token` are required by the time a command actually talks to the Coordinator; `group`/`user` are optional everywhere.
 
 `npm install -g` creates `~/.config/thub/agent.json` for you (blank `url`/`token`, so nothing works until you set them) if it doesn't already exist — a re-install never overwrites it. Fill it in with `thub config set`:
 
@@ -24,7 +24,6 @@ thub config set key thk_...       # your access key: from an admin (Users), or y
 thub whoami                       # jane (user) <jane@example.com>
 thub key show                     # its last characters, created, last used
 thub key rotate                   # a new key; the old one stops at once (saved here if it came from here)
-thub config set user "Your Name"     # optional default --user
 ```
 
 ## Commands
@@ -50,13 +49,8 @@ Key options for `thub run`. **On the Client** names the environment variable the
 | `--type hw\|sw` | Required resource type. | `JOB_TYPE` |
 | `--label <l>` | Required labels (repeatable; a board is `--label board:<name>`): the job runs only on a runner that has all of them. Each 1–64 characters, no whitespace, commas or semicolons. | `JOB_LABEL`, `JOB_LABEL_<n>` |
 | `--client <name\|id>` | Run on this specific Client (resource name or id) only; the job waits in that Client's queue even if other matching resources are idle. | `JOB_CLIENT` |
-| `--user <name>` | Free-text job owner — a label, not an identity. Falls back to `THUB_USER` / `thub config set user <name>`. | `JOB_USER` |
-| `--command <string>` | **Required.** The task's entry point: a shell command the Client runs (`sh -c`) in the task's work directory — the `--git-repo` checkout, else an empty directory — after preparing its inputs. Its exit code is the verdict. On HW it flashes the board itself (the Client doesn't); it gets `THUB_DUT_STLINK`/`_UART`/`_USB`/`_HOST`/`_CONTAINER`, `THUB_DOWNLOAD_<n>`, `THUB_DOWNLOADS_DIR`, `THUB_GIT_COMMIT`, `THUB_SUITE`, `THUB_META_*`. | `JOB_COMMAND` |
+| `--command <string>` | **Required.** The task's entry point: a shell command the Client runs (`sh -c`) in the job's work directory, after the downloads. It clones repositories and runs containers itself (see Git and Docker below), with credentials from `--env`. Exit code 0 = PASSED. | `JOB_COMMAND` | `JOB_COMMAND` |
 | `--download-file <url>` | A file the Client downloads before running the command (repeatable, `http(s)`), into the job's `downloads/` directory. | `JOB_DOWNLOAD_FILE`, `JOB_DOWNLOAD_FILE_<n>` (URLs); `THUB_DOWNLOAD_<n>` (local paths) |
-| `--docker-image <name>` | SW only: a Docker image the Client runs as the **DUT** (an emulator the tests talk to, at `$THUB_DUT_HOST` / `$THUB_DUT_CONTAINER`) — any SW Client runs it; without one, an SW job has no DUT container. It's not where `--command` runs: to run the tests in an image, see [Docker](#docker). | `JOB_DOCKER_IMAGE` |
-| `--git-repo <url> [<branch>\|<tag>\|<commit>]` | A git repository the Client clones (default ref: the default branch); the command runs in the checkout. | `JOB_GIT_REPO_URL`, `JOB_GIT_BRANCH` |
-| `--depth <n>` | With `--git-repo`: commits to fetch, default `1`; `0` = full history. | `JOB_GIT_DEPTH` |
-| `--git-options <string>` | With `--git-repo`: extra git options placed between `git` and its subcommand on the Client, e.g. `'-c core.sshCommand="ssh -i ~/.ssh/lab_key -p 2222"'`. Shell-quoted (no shell run). Stored with the job, so reference key files rather than inlining secrets. | `JOB_GIT_OPTIONS` |
 | `--env <vars>` | Environment variables for every command the Client runs for the job (git and `--command`): `NAME=value[,NAME=value]`, repeatable; `--env NAME` alone takes the value from your shell. Any names — none means anything to the Agent or the Client (only `THUB_*`, `JOB_*`, `GIT_TERMINAL_PROMPT`, `GIT_ALLOW_PROTOCOL` are refused). Every value is a secret: it reaches only the Client running the job; the Coordinator masks it and drops it when the job ends. | each `NAME` itself |
 | `--suite <name>` | Passed to the command as `THUB_SUITE`. | `JOB_SUITE` (also `THUB_SUITE`) |
 | `--arg <value>` | Extra argument for the command, as `"$@"` (repeatable). | `JOB_ARG`, `JOB_ARG_<n>` (and `"$@"`) |
@@ -85,35 +79,37 @@ Exit codes make the Agent usable as a CI step:
 
 ## Examples
 
-**Run a task** — download the firmware, check out the tests at a tag, flash and test (HW):
+**Run a task** — download the firmware, clone the tests at a tag, flash and test (HW):
 
 ```bash
+export GH_TOKEN=…   # read access to the tests repository
 thub run --type hw --label board:nucleo-f401re \
-  --download-file "$IMAGE_URL" \
-  --git-repo https://github.com/yourorg/firmware-tests.git v1.4.0 \
-  --command 'st-flash --serial "$THUB_DUT_STLINK" --reset write "$THUB_DOWNLOAD_1" 0x08000000 && ./ci/test.sh "$@"' \
+  --download-file "$IMAGE_URL" --env GH_TOKEN \
+  --command 'git clone --depth 1 --branch v1.4.0 "https://x-access-token:$GH_TOKEN@github.com/yourorg/firmware-tests.git" . &&
+             st-flash --serial "$THUB_DUT_STLINK" --reset write "$THUB_DOWNLOAD_1" 0x08000000 && ./ci/test.sh "$@"' \
   --arg --junit --wait
 ```
 
-**SW task against a DUT emulator image of your own** (the command runs on the Client host and talks to the emulator):
+**SW task against an emulator container of your own** (started and removed by the command):
 
 ```bash
-thub run --type sw --docker-image registry.lab.local:5000/dut-emulator:2026.08 \
-  --git-repo git@github.com:yourorg/firmware-tests.git main --depth 20 \
-  --command 'make test DUT="$THUB_DUT_HOST"' --wait
+thub run --type sw --download-file "$IMAGE_URL" \
+  --command 'dut="thub-$THUB_JOB_ID" && trap "docker rm -f $dut >/dev/null" EXIT &&
+             docker run -d --name "$dut" -p 127.0.0.1:5555:5555 -v "$THUB_DOWNLOADS_DIR:/downloads:ro" registry.lab.local:5000/dut-emulator:2026.08 &&
+             make test DUT=127.0.0.1:5555' --wait
 ```
 
 **Associate a CI/CD job id with the internal job id:**
 
 ```bash
-thub run --type sw --download-file "$IMAGE_URL" --git-repo "$TESTS_REPO" --command ./ci/test.sh \
+thub run --type sw --download-file "$IMAGE_URL" --command ./ci/test.sh \
   --meta ciJobId="$GITHUB_RUN_ID" --wait
 thub status A-00123 --json | jq '.spec.meta.ciJobId'
 ```
 
 **Pass extra metadata** — `--meta key=value` reaches the command as `THUB_META_<KEY>` (`ciJobId` → `THUB_META_CI_JOB_ID`).
 
-**Dry-run the pipeline** — proves the Coordinator↔Client plumbing works without real hardware, a real emulator image, or reachable downloads:
+**Dry-run the pipeline** — proves the Coordinator↔Client plumbing works without real hardware or reachable downloads:
 
 ```bash
 thub run --type sw --download-file https://does-not-exist.invalid/app.bin \
@@ -122,20 +118,15 @@ thub run --type sw --download-file https://does-not-exist.invalid/app.bin \
 
 **Run in a resource group:** there's no `--group` option. An admin or maintainer gives your user (or a CI token) one group on the dashboard, and every job it submits runs only on that group's resources; `thub whoami` shows it.
 
-**Label a job with its owner** — purely informational, shows up on the dashboard, in `thub jobs`, and on the Client's own console:
-
-```bash
-thub run --type hw --label board:nucleo-f401re \
-  --git-repo "$TESTS_REPO" --command ./ci/test.sh --user "Your Name" --wait
-```
+**Who submitted a job** comes from your key: your username (a CI token: its name), shown on the dashboard, in `thub jobs`, on the Client's console and as `JOB_USER`. There's no `--user`.
 
 ## Environment variables and secrets
 
-`--env NAME=value[,NAME=value]` (repeatable) sets variables for every command the Client runs for the job: git and `--command`. The names are yours; none means anything to the Agent or the Client. `--env NAME` alone takes the value from your own environment, so a secret stays off the command line and out of CI logs:
+`--env NAME=value[,NAME=value]` (repeatable) sets variables for `--command`. It's how all data and secrets reach a job (a git token, a registry password, an API key). The names are yours; none means anything to the Agent or the Client. `--env NAME` alone takes the value from your own environment, so a secret stays off the command line and out of CI logs:
 
 ```bash
 export API_TOKEN=…
-thub run --type sw --git-repo "$TESTS_REPO" \
+thub run --type sw \
   --env TARGET=staging --env API_TOKEN \
   --command './run-tests.sh --target "$TARGET"' --wait
 ```
@@ -147,10 +138,24 @@ thub run --type sw --git-repo "$TESTS_REPO" \
 - The Coordinator replaces the values with `***` once the job ends.
 - A `--dry-run` shows every value as `***`, whatever its name.
 
-Your command's output is the job's log, so don't print secrets. Everything else — `--command`, `--arg`, `--meta`, `--git-options` — is stored as is and visible, so never put secrets there.
+Your command's output is the job's log, so don't print secrets. Everything else — `--command`, `--arg`, `--meta`, `--download-file` — is stored as is and visible, so never put secrets there.
+
+## Git
+
+The Client doesn't clone anything (and doesn't need git itself): the command does, into its work directory, with a token from `--env`:
+
+```bash
+export GH_TOKEN=…
+thub run --type sw --env GH_TOKEN,REF=main \
+  --command 'git clone --depth 1 --branch "$REF" "https://x-access-token:$GH_TOKEN@github.com/yourorg/tests.git" . && ./ci/test.sh' --wait
+```
+
+For SSH, pass the private key itself as `--env` (base64) and use it via `GIT_SSH_COMMAND` from a file in the job directory, which is deleted with the job (main README, §7.2).
 
 ## Docker
 
+The Client doesn't pull images or start containers (and doesn't need Docker itself): the command does.
+
 **Log in to a custom registry:** in `--command`, with credentials passed as `--env` under any names. Point `DOCKER_CONFIG` at the job's work directory first, so the login is deleted with the job rather than left in the Client user's `~/.docker` for later jobs:
 
 ```bash
@@ -163,21 +168,13 @@ thub run --type hw \
   --wait
 ```
 
-**Pull an image as the DUT:** `--docker-image` is pulled by the Client before the command runs, as its service user. For a private registry, log in once on the Client host as that user: `sudo -u thub docker login registry.lab.local:5000`.
-
-```bash
-thub run --type sw --docker-image registry.lab.local:5000/dut-emulator:2026.08 \
-  --git-repo "$TESTS_REPO" --command './ci/test.sh --dut "$THUB_DUT_HOST"' --wait
-```
-
-**Run the command inside a container:** `--command` starts on the Client host in the work directory (`$THUB_WORK_DIR`, the `--git-repo` checkout). Start the container from it, mounting that directory:
+**Run the command inside a container:** `--command` starts on the Client host in the work directory (`$THUB_WORK_DIR`). Clone into it, then start the container mounting it:
 
 ```bash
 thub run --type sw \
-  --env DOCKER_REGISTRY=registry.lab.local:5000,DOCKER_USER=ci --env DOCKER_PASSWORD \
-  --git-repo git@bitbucket.org:yourorg/web-ui-tests.git main \
-  --git-options '-c core.sshCommand="ssh -i /home/thub/.ssh/id_ed25519 -o StrictHostKeyChecking=accept-new"' \
-  --command 'export DOCKER_CONFIG="$THUB_WORK_DIR/.docker" &&
+  --env DOCKER_REGISTRY=registry.lab.local:5000,DOCKER_USER=ci --env DOCKER_PASSWORD --env GH_TOKEN \
+  --command 'git clone --depth 1 "https://x-access-token:$GH_TOKEN@github.com/yourorg/web-ui-tests.git" . &&
+             export DOCKER_CONFIG="$THUB_WORK_DIR/.docker" &&
              echo "$DOCKER_PASSWORD" | docker login "$DOCKER_REGISTRY" --username "$DOCKER_USER" --password-stdin &&
              docker run --rm -v "$THUB_WORK_DIR:/work" -w /work "$DOCKER_REGISTRY/python:3.14" ./run-tests.sh' \
   --wait
@@ -199,21 +196,19 @@ thub run --type sw \
   --wait
 ```
 
-The Client host needs Docker and the Client's user in the `docker` group; SW Clients have both. Add `--dry-run` to see every command a job would run on the Client (every `--env` value shown as `***`) without running any. More in the main README, §7.2.
+The Client host needs Docker and the Client's user in the `docker` group for these (install Docker before the Client). Add `--dry-run` to see every command a job would run on the Client (every `--env` value shown as `***`) without running any. More in the main README, §7.2.
 
 ## Client environment variables
 
 On the Client, the job's `--command` gets every option above as a `JOB_<NAME>` variable (the **On the Client** column). A variable whose option wasn't given is unset. A repeatable option gives `<NAME>` with all values plus `<NAME>_<n>` for each one. It also gets:
 - its `--env` variables, under their own names;
-- `THUB_JOB_ID`, `THUB_WORK_DIR` (where it runs), `THUB_GIT_COMMIT`, `THUB_DOWNLOADS_DIR`, `THUB_DOWNLOADS`, `THUB_DOWNLOAD_<n>` (local paths), `THUB_SUITE` and `THUB_META_<KEY>`;
-- the DUT's `THUB_DUT_UART[_<n>]`, `THUB_DUT_USB[_<n>]`, `THUB_DUT_STLINK[_<n>]` (HW), or `THUB_DUT_HOST` and `THUB_DUT_CONTAINER` (SW with `--docker-image`).
+- `THUB_JOB_ID`, `THUB_WORK_DIR` (where it runs), `THUB_DOWNLOADS_DIR`, `THUB_DOWNLOADS`, `THUB_DOWNLOAD_<n>` (local paths), `THUB_SUITE` and `THUB_META_<KEY>`;
+- the DUT's `THUB_DUT_UART[_<n>]`, `THUB_DUT_USB[_<n>]`, `THUB_DUT_STLINK[_<n>]` (HW).
 
 `THUB_*` and `JOB_*` names can't be set with `--env`. The full list is in the main README, §7.4.
 
 ```bash
-thub run --type sw --git-repo git@bitbucket.org:yourorg/tests.git main --depth 1 \
-  --command 'git clone --depth "$JOB_GIT_DEPTH" ${JOB_GIT_BRANCH:+--branch "$JOB_GIT_BRANCH"} "$JOB_GIT_REPO_URL" src && cd src && ./run-tests.sh' \
-  --wait
+thub run --type hw --label uart --suite smoke --command 'echo "suite $JOB_SUITE on $JOB_LABEL" && ./ci/test.sh' --wait
 ```
 
 ## Job status and PASS/FAIL
@@ -232,7 +227,7 @@ thub jobs --mine --state FAILED
 **From a script:** `thub status <jobId> --json` prints the job once, with `state`, `exit_code`, `summary`, `message` and `resource.name`. It exits with the verdict code, or `5` while the job is still queued or running:
 
 ```bash
-JOB=$(thub run --type sw --git-repo "$TESTS_REPO" --command ./ci/test.sh --detach --json | jq -r .jobId)
+JOB=$(thub run --type sw --command ./ci/test.sh --detach --json | jq -r .jobId)
 while thub status "$JOB" --json > job.json; [ $? -eq 5 ]; do sleep 10; done
 jq -r '"\(.state) exit=\(.exit_code) failed=\(.summary.failed // 0)"' job.json   # PASSED exit=0 failed=0
 ```
@@ -250,8 +245,9 @@ test-sw:
     - run: |
         npx -y @andrian.yablonskyy/thub-agent run --type sw \
           --download-file "${{ needs.build.outputs.image_url }}" \
-          --git-repo "$GITHUB_SERVER_URL/$GITHUB_REPOSITORY.git" "$GITHUB_SHA" \
-          --command ./ci/sw-tests.sh --suite full --wait
+          --env GH_TOKEN="${{ secrets.TESTS_READ_TOKEN }}",REPO="$GITHUB_REPOSITORY",SHA="$GITHUB_SHA" \
+          --command 'git init -q . && git fetch -q --depth 1 "https://x-access-token:$GH_TOKEN@github.com/$REPO.git" "$SHA" &&
+                     git checkout -q FETCH_HEAD && ./ci/sw-tests.sh' --suite full --wait
 ```
 
 If the GitHub job is canceled, the runner sends `SIGINT` to the Agent. In `--wait` mode (CI), that's treated as a cancel request (`POST /jobs/:id/cancel`) before exiting, so abandoned CI jobs don't hold hardware. In interactive mode, Ctrl-C only detaches.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@andrian.yablonskyy/thub-agent",
-  "version": "1.1.3",
+  "version": "1.1.4",
   "description": "TestHub Agent CLI — the single entry point CI/CD and developers use to submit and follow test jobs",
   "bin": {
     "thub": "./src/cli.js"
@@ -12,7 +12,7 @@
     "lint:fix": "eslint . --fix"
   },
   "dependencies": {
-    "@andrian.yablonskyy/thub-common": "^1.1.2",
+    "@andrian.yablonskyy/thub-common": "^1.1.3",
     "commander": "^13.1.0"
   },
   "devDependencies": {

package/src/cli.js

@@ -18,10 +18,9 @@
 const { Command, Option } = require('commander'),
   {
     ApiClient, EXIT_CODES, ACTIVE_JOB_STATES, exitCodeForJobState, PACKAGES, fetchLatestVersion, isNewer, isValidVersion, formatDateTime,
-    splitArgs,
     parseEnvList
   } = require('@andrian.yablonskyy/thub-common'),
-  { resolveConnection, resolveUser, writeConfigFile, readConfigFile, CONFIG_PATH } = require('./config'),
+  { resolveConnection, writeConfigFile, readConfigFile, CONFIG_PATH } = require('./config'),
   { parseDurationSec } = require('./duration'),
   { followJob } = require('./streaming'),
   { applyRequestedUpdate, installAgent, version } = require('./self-update');
@@ -57,8 +56,8 @@ function client(){
   return new ApiClient({ baseUrl: url, token, userAgent: `thub-agent/${version}` });
 }
 
-// --command (mandatory), --download-file (repeatable), --docker-image (SW
-// only) and --git-repo <url> [ref] --depth <n> -> the job spec's task fields.
+// --command (mandatory), --download-file (repeatable) and --env -> the job
+// spec's task fields. A git checkout or a container is the command's own job.
 // Checked here too, so mistakes explain themselves before anything is sent.
 function taskFromOptions(opts){
   const downloads = opts.downloadFile.map((url) => {
@@ -69,38 +68,6 @@ function taskFromOptions(opts){
     }),
     task = { command: opts.command, args: opts.arg, suite: opts.suite, ...(downloads.length ? { downloads } : {}) };
 
-  if (opts.dockerImage){
-    if (opts.type !== 'sw'){
-      throw usageError('--docker-image only works for SW jobs (--type sw): an HW job runs on the physical board');
-    }
-    task.image = opts.dockerImage;
-  }
-
-  if (opts.depth !== undefined && !opts.gitRepo){
-    throw usageError('--depth only applies to --git-repo');
-  }
-  if (opts.gitOptions !== undefined && !opts.gitRepo){
-    throw usageError('--git-options only applies to --git-repo');
-  }
-  if (opts.gitOptions){
-    try {
-      splitArgs(opts.gitOptions);
-    }
-    catch (err){
-      throw usageError(`--git-options: ${err.message}`);
-    }
-  }
-  if (opts.gitRepo){
-    const [url, ref, ...extra] = opts.gitRepo;
-    if (extra.length){
-      throw usageError(`--git-repo takes a URL and at most one branch, tag or commit (got: ${opts.gitRepo.join(' ')})`);
-    }
-    const depth = opts.depth === undefined ? 1 : Number(opts.depth);
-    if (!Number.isInteger(depth) || depth < 0){
-      throw usageError(`--depth ${opts.depth}: must be a whole number (0 = full history)`);
-    }
-    task.git = { url, ...(ref ? { ref } : {}), depth, ...(opts.gitOptions ? { options: opts.gitOptions } : {}) };
-  }
   let env;
   try {
     env = parseEnvList(opts.env);
@@ -160,15 +127,12 @@ program
     'Run on this specific Client (resource name or id) only; the job waits in that Client\'s queue ' +
       'even if other matching resources are idle.'
   )
-  .option(
-    '--user <name>',
-    'Free-text job owner, shown on the Client and the dashboard to tell whose job is whose ' +
-      '— purely a label, not an identity. Overrides THUB_USER / config file.'
-  )
   .requiredOption(
     '--command <string>',
-    'The task\'s entry point: a shell command the Client runs (sh -c) in the task\'s work directory — the --git-repo ' +
-      'checkout if given — after downloading --download-file files. --arg values arrive as "$@"'
+    'The task\'s entry point: a shell command the Client runs (sh -c) in the job\'s work directory, after downloading ' +
+      '--download-file files. --arg values arrive as "$@". Anything else the job needs it does itself — e.g. ' +
+      '`git clone "https://x-access-token:$GH_TOKEN@github.com/org/tests.git" . && ./ci/test.sh` or ' +
+      '`docker run --rm "$IMAGE" ./run.sh` — with credentials passed by --env'
   )
   .option(
     '--download-file <url>',
@@ -177,27 +141,11 @@ program
     collectRepeatable,
     []
   )
-  .option(
-    '--docker-image <name>',
-    'SW jobs only: a Docker image the Client runs as the job\'s DUT container, next to --command (e.g. registry.lab:5000/emu:1); ' +
-      'pulled from the registry it names, else Docker Hub. Without it, an SW job has no DUT container'
-  )
-  .option(
-    '--git-repo <url...>',
-    'A git repository the Client clones before running --command, then runs it there: <url> [<branch>|<tag>|<commit>] ' +
-      '(https://, ssh://, git:// or user@host:path; default ref: the default branch)'
-  )
-  .option('--depth <n>', 'With --git-repo: how many commits to fetch (default 1; 0 = full history)')
-  .option(
-    '--git-options <string>',
-    'With --git-repo: extra git options, placed between `git` and its subcommand on the Client (shell-quoted, no shell run), ' +
-      'e.g. \'-c core.sshCommand="ssh -i ~/.ssh/lab_key -p 2222"\'. Stored with the job — reference key files, don\'t inline secrets'
-  )
   .option(
     '--env <vars>',
-    'Environment variables for every command the Client runs for the job (git, --command): ' +
+    'Environment variables for --command — how data and secrets (a git token, a registry password) reach the job: ' +
       'NAME=value[,NAME=value] (repeatable; a value may contain commas); --env NAME alone takes its value from this shell. ' +
-      'Any names (except THUB_*, JOB_*, GIT_TERMINAL_PROMPT, GIT_ALLOW_PROTOCOL). ' +
+      'Any names except THUB_* and JOB_*. ' +
       'Values reach only the Client running the job; the Coordinator masks them and drops them when the job ends',
     collectRepeatable,
     []
@@ -228,15 +176,13 @@ program
         c = client(),
         labels = requiredLabels(opts),
         meta = Object.fromEntries(opts.meta.map((kv) => kv.split(/=(.*)/s).slice(0, 2))),
-        user = resolveUser({ user: opts.user }),
 
         spec = {
-          // No group: the Coordinator uses this key's, set on the dashboard (§13.1).
+          // No group or user: the Coordinator takes both from this key (§13.1).
           target: { type: opts.type, labels, ...(opts.client ? { client: opts.client } : {}) },
           ...task,
           timeoutSec: parseDurationSec(opts.timeout),
           ...(opts.priority !== undefined ? { priority: opts.priority } : {}),
-          ...(user ? { user } : {}),
           ...(Object.keys(meta).length ? { meta } : {}),
           ...(opts.dryRun ? { dryRun: true } : {})
         },
@@ -385,15 +331,17 @@ function formatBytes(bytes){
 const config = program.command('config').description('Manage local Agent configuration');
 config
   .command('set')
-  .argument('<name>', 'url | key | user')
+  .argument('<name>', 'url | key')
   .argument('<value>')
   .action((name, value) => {
     // `token` is the old name of `key`.
     const setting = name === 'token' ? 'key' : name;
-    if (!['url', 'key', 'user'].includes(setting)){
+    if (!['url', 'key'].includes(setting)){
       console.error(setting === 'group'
         ? 'Error: a job\'s group is set on the dashboard now (Users / CI tokens), not in the Agent'
-        : 'Error: the setting must be "url", "key", or "user"');
+        : setting === 'user'
+          ? 'Error: a job\'s user comes from your access key now (thub whoami shows it), not from the Agent'
+          : 'Error: the setting must be "url" or "key"');
       process.exit(EXIT_CODES.USAGE);
     }
     const { token: _old, ...current } = readConfigFile();

package/src/config.js

@@ -65,13 +65,4 @@ function resolveConnection(flags = {}){
   return { url, token, keySource };
 }
 
-// Optional default for `--user` (§4.3/§7.1) — flags > env > file, like
-// url/token. Purely a label (who submitted this job), not an
-// identity: unset is fine, and nothing on the Coordinator side enforces
-// or authenticates it.
-function resolveUser(flags = {}){
-  const file = { ...readJsonFile(PACKAGE_DEFAULT_CONFIG_PATH), ...readConfigFile() };
-  return flags.user || process.env.THUB_USER || file.user || undefined;
-}
-
-module.exports = { CONFIG_PATH, readConfigFile, writeConfigFile, resolveConnection, resolveUser };
+module.exports = { CONFIG_PATH, readConfigFile, writeConfigFile, resolveConnection };