Skip to content

CLI: agent-experience gaps found driving Rainier from an automated session #82

Description

@jiashuoz

Observations from a long operator/agent session driving Rainier end to end today (image publish, cell deploy, runner roll, verification). All are about using the CLI non-interactively — from a script or from another agent — rather than by hand.

1. No way to run a command in an existing session

rainier new -- CMD runs a command at creation, and rainier attach is interactive. There is no rainier exec <session> -- CMD.

The consequence is awkward: to hand a running session a task, I had to create it with a command that polls for a file, then rainier push the file in:

rainier new --name agent --detach -- /bin/sh -c 'until [ -f /workspace/task/task.md ]; do sleep 2; done; ...'
rainier push ./task agent:/workspace/task

An exec would remove the poll-and-push dance entirely, and is the single biggest ergonomic gap for scripted or agent-driven use.

2. No non-interactive way to read a detached session's output

There is no rainier logs. For a --detached session the only way to recover what a command printed is rainier attach, which streams a TTY — so output arrives wrapped in ANSI cursor-positioning escapes and column padding:

[0m[2J[H[1;1Hclaude         /usr/local/bin/claude   ...  [2;1Hcodex ...

Every consumer has to strip that to recover plain stdout, and column-padded lines can be truncated. rainier info gives the exit status (Process: Exited (0)) but not the output.

Suggestion: rainier logs <session> for raw stdout/stderr, and/or --json on the existing commands.

3. rainier agent status says ready for an expired credential

AGENT   STATUS  SINCE
claude  ready   25h5m9s
note: "ready" means a stored credential; Rainier does not verify it with the provider

The footnote is accurate, but ready is the wrong word for "a credential exists, validity unknown". A session with this exact status failed with Failed to authenticate: OAuth session expired and could not be refreshed.

This cost real debugging time: an authentication gate looked met while no session could actually authenticate, and the CLI's own summary line (Claude: ready) agreed. Suggestions, in order of preference:

  • rename the state to stored, keeping ready for something actually verified
  • add rainier agent status --verify for an explicit provider check
  • surface credential age prominently — a token well past its expected lifetime is worth flagging

4. No bulk cleanup for finished sessions

Failed sessions persist in rainier ls indefinitely and are removed one at a time. After a few days of testing the list is mostly dead entries:

codex-qual-980c96b  Failed  -  Unavailable  48h0m12s
dev5                Failed  -  Unavailable  95h12m17s
dev4                Failed  -  Unavailable  95h11m7s

Something like rainier delete --state failed (or a --older-than) would help. Deleting sessions carries work-loss risk, so this should require an explicit state or age filter rather than a bare --all.


Filed as a TODO for discussion, not a claim about priority. Happy to split into separate issues.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions