[Bug] Several commands return results that automation cannot consume

Start by tracing the fs-git and fs commands named in the report, then consult ti-cli-reference.md and the recorded ~/.ti/logs/ti.jsonl exit data. Reproduce the JSON, status, exit-code, and macOS WebDAV unmount observations separately. Done means the five behaviors are fixed or their intended contracts are explicitly confirmed and documented.

ti version

0.2.7 (6c950c77a601d0d55394c4b2f64483ae93d522db, 2026-09-27), bundled ti-drive9 companion 60b63d6

Command family

fs-git

Operating system and architecture

Ubuntu, linux/amd64, for the git workspace commands. macOS 14.6, darwin/arm64, for the rest.

Problems 1 and 2 are fs-git. Problems 3 and 4 are fs. Problem 5 is a mount concern. The
dropdown takes one value, so this is filed under fs-git.

Summary

Five problems that share one consequence. A script cannot learn the outcome of a command from
its result, so it has to parse human-readable text or guess.

Covers observations 1, 6, 3, 12, and 5 from a review of the TiDB Cloud Filesystem
documentation.

Problem 1: clone-git-workspace and add-git-worktree return empty JSON

Command

ti fs-git clone-git-workspace --mount-path <mounted-path> --repo-url <repo-url>
ti fs-git add-git-worktree --mount-path <mounted-path> --branch <branch>

Reproduction steps

1. Run ti fs-git clone-git-workspace against a mounted file system path.
2. Capture stdout and parse it.
3. Repeat with ti fs-git add-git-worktree.

Expected behavior

The result identifies what was created, so the next command can use it.

Actual behavior

Every field in the JSON is an empty string, tree_entries is 0, and timestamps are
zero values. The real workspace ID appears only on stderr. An automated caller cannot capture
what it just created without scraping stderr.

Problem 2: remove-git-worktree warns, leaves a directory, and reports an empty ID

Command

ti fs-git remove-git-worktree --mount-path <mounted-path> --worktree-path <worktree-path>

Actual behavior

A clean removal prints a warning and still exits 0:

warning: could not remove empty worktree root ...: directory not empty

The empty directory is left on disk, and the result JSON reports an empty workspace_id,
which is the same reporting gap as problem 1. So the caller is told about a failure that is
reported as success, and cannot identify the resource it just acted on.

Problem 3: create-file-system and list-file-systems disagree on status

Command

ti fs create-file-system --display-name demo --wait
ti fs list-file-systems

Actual behavior

create-file-system reports "status": "ready". list-file-systems reports
"status": "active" for the same resource. A caller that waits for one value never sees it if
it polls the other command.

Problem 4: exit code 5 exists and is documented nowhere

Reproduction steps

ti fs delete-file-system-token --file-system-id "<fs-id>" --token-id 11111111-2222-3333-4444-555555555555

Actual behavior

ti [ERROR]: remote resource not found: DELETE /v1/tokens/11111111-2222-3333-4444-555555555555

Exit code 5, with error_category api and error_code api.not_found in
~/.ti/logs/ti.jsonl.

ti-cli-reference.md documents exit code 2 for a missing command and 130 for an interrupted
interactive configuration, and otherwise says only that failures are nonzero. No document
lists the full set. Across my local log I have observed 0, 1, 2, 3, 4, and 5 from ti fs.

A path that does not exist inside a file system returns 1 rather than 5, so the two cases need
separating in any documented list.

The request here is a decision as much as a fix: please confirm whether the exit codes are
intended to be stable, because automation that branches on them needs to know the full set.

Problem 5: on macOS over WebDAV the helper process outlives the unmount

Command

ti fs mount-file-system --mount-path ~/mnt --driver webdav
ls ~/mnt
ti fs unmount-file-system --mount-path ~/mnt
ps -eo pid,command | grep ti-drive9

Reproduction steps

1. Mount a file system on macOS with --driver webdav.
2. Read the mount once.
3. Unmount, and remove the mount directory.
4. Look for ti-drive9 in the process list.

Actual behavior

unmount-file-system reported "status": "unmounted", mount lists nothing, and the mount
directory no longer exists, yet the helper was still running hours later:

ti-drive9 mount --foreground --mode webdav :/ /Users/<user>/fix1-test

Not reproducible on Linux over FUSE, where the helper exited within about two seconds on three
consecutive unmounts. This appears specific to the macOS WebDAV path rather than to unmount in
general.

Note on version: this one was observed on 0.2.4. The other four problems in this issue were
re-measured on 0.2.7. I have not re-mounted on macOS since upgrading, so please treat problem 5
as a 0.2.4 observation until confirmed again.

Sensitive-data confirmation

No API keys, file system or Vault tokens, database credentials, connection strings, SQL, or
customer data appear above. File systems used for these measurements were deleted afterwards,
and the local user name in the process line has been replaced.