wick-cli-channel

Talking to this session from a shell

Some work does not fit in a turn. A build takes four minutes, a deploy takes twenty, a migration takes as long as it takes. You start it, and then you have a problem that is not about the work at all: how do you find out it finished?

The old answer was to schedule a wake-up and look. That is a guess about somebody else's clock — too early and you look at a half-finished build, too late and the person waiting has been waiting for nothing. And a build that dies at 03:00 stays silent until the next poll.

The better answer: let the WORK do the telling.

mint a token  →  run the job detached with the token in its env  →  end the turn
                                     ↓
                 the job finishes (or fails) and sends a message
                                     ↓
                 this session wakes on it, like any other message

1. Mint a token

wick_cli_token                                   # 30m
wick_cli_token {"ttl": "90m", "note": "build 0.1.261"}

There is no revoke and no list: a token is a signed statement rather than a row somewhere, and at a two-hour ceiling waiting it out IS the answer. To cancel every outstanding one at once, rotate the app's session secret.

You get back the token, the base_url to hit, the exact endpoints, when it expires, and a ready-to-paste command.

The channel only answers this machine. A request from another host is refused before the token is even read, and so is one that arrived through a proxy (the forwarding headers give it away). The work this exists for runs here, so off-box access is not a use case — and a leaked token is worth nothing anywhere else.

The address is therefore always loopback: 127.0.0.1:<port>, or localhost:<port>. Both are tried because a host allowlist can name one and not the other. If neither answers, add it — support-tools config allowed-origins add http://127.0.0.1:<port> — which is a configuration change, not a hole in the rule.