Git push from a session

Pushing from a session needs the installation's forge to be turned on. It is not on in eu1 yet, so in Ciresk's cloud every ciresk dev push is refused today with push_unavailable. Everything on this page that does not push (checkpoints, stopping and continuing a remote session, pushing from your own checkout) works without it.

Which sessions push

A push from a local session is refused with not_cloud_writer; the answer tells you to push from your own checkout.

Push

Run it in the worktree whose remote session you want to push:

ciresk dev push
ciresk dev push --pr
ciresk dev push --pr --base main --title "fix the invoice rounding"

--pr needs a base: with no branch checked out and no --base, it is refused before anything is sent.

What a push does, in one step on the host that runs the session:

1. Takes a checkpoint of the workspace, exactly as ciresk dev checkpoint does.
2. Builds one commit from what changed since the session's base: the commit the session started from, or the last commit it pushed. Only the changed files are applied, so changes that landed on the base branch since the session started are never reverted.
3. Checks the commit for workflows that would run on the session's branch (see Workflows).
4. Pushes it to refs/heads/ciresk/<session>, fast-forward only.
5. With --pr, opens the pull request from that branch into --base, or finds the one already open.

When nothing changed since the base, the first push still creates the session's branch, at the base commit, so a pull request asked for with it has a branch to come from.

The commit:

• Branch: always refs/heads/ciresk/<session>. No flag names another branch, a tag, a remote or a force. A session continued from a stopped or ended one keeps writing the first session's branch.
• Parent: always the session's base. If the branch moved to a commit the session did not push, the push is refused with non_fast_forward and the branch is left as it is.
• Author: the session's owner, with the name and email your organization's directory gives them; without them, the owner's id at an address that receives no mail. Committer: Ciresk <[email protected]>.
• Message: the title, then these trailers:

fix the invoice rounding

Ciresk-Session: devs_...
Ciresk-Pushed-By: user:01H...
Ciresk-Agent: agent:01H...

• Pull request body: the session id and the checkpoint's tree root.

Output:

pushed 3f9c2a1 to refs/heads/ciresk/devs_...
files: 4
pull request: https://github.com/acme/app/pull/812 (opened)

A push with nothing new since the last one prints already pushed <sha>. A pull request that was already open prints (existing). --json returns the result as data:

A push may take up to about two minutes. If it is still running when the command stops waiting, the command prints still pushing, exits with code 7 and names the call to make: run ciresk dev push --idempotency-key <key> with the same key to get the result, without pushing twice. A push that is cut off because the session stopped or was killed is refused with session_ended, and nothing that had not reached the forge was pushed.

ciresk dev status shows the session's last push as pushed: <short sha> <pull request url>.

Workflows

A session never pushes a commit that would start a GitHub Actions workflow on its branch, because such a workflow would run the session's code with your repository's secrets. The push is refused with push_unsafe_workflows, and nothing is pushed, when:

• the change touches anything under .github/workflows/; or
• a workflow in the commit (any .yml or .yaml file directly under .github/workflows/, usually your base branch's own) runs on a push to ciresk/<session> or on the creation of a branch. That is a workflow with a create trigger, or with a push trigger that has no branch filter, a paths filter alone, or a branches or branches-ignore list that does not leave ciresk/<session> out. A workflow file that does not parse counts as running, and so does a branch pattern with ?, +, [ or \.

To fix it, change the workflow on your base branch, from your own checkout, then push again:

on:
  push:
    branches-ignore: ['ciresk/**']
  pull_request:

Give every push trigger branches-ignore: ['ciresk/**'] (or a branches list that does not match ciresk/..., such as [main]), and drop any create trigger. A change to .github/workflows/ itself is always made from your own checkout.

A change whose path has a .git component, in any case or in a spelling some file system reads as .git, is refused with push_unsafe_path. Delete that path in the session, then push again.

The push credential

A push uses an organization secret of purpose git, created by an admin:

ciresk dev secrets set github-push --purpose git --host github.com --repo github.com/acme/app < token.txt

• For a GitHub forge the value is a token; for an ssh forge it is an openssh private key (a deploy key).
• --host binds it to the forge's git host. When several git secrets for that host reach the session, the first by name is used.
• --repo, --template and --agent-sessions select which sessions get it, as for every secret. A session an agent, a service or a key started gets it only when the secret was set with --agent-sessions.
• The session itself never sees it: a git secret gets no placeholder in the session and never goes through the session's egress proxy. It is fetched for each push on the host and kept on no disk, and it is never in an answer, a log or an audit record.
• No secret of purpose proxy may name the forge's host: the session's own requests to that host would carry it, so the session could push with it around its branch. While one does, every push is refused with push_credential_proxied; set that secret again with --purpose git, or remove it.
• Give the token only what a push needs: contents and pull requests, write.

See secrets.md for creating, listing and removing secrets.

Who may push

The session's owner, or a member the owner shared the session with as use (see sessions.md). People, agents and services may call it, with the dev:sessions.attach scope. Agents push through the MCP tool dev_session_push, with the same base, pr and title arguments and an idempotency_key (see mcp.md). Only a person can create the git secret.

Refusals

A worktree with no git remote is refused before anything is sent: add one with git remote add origin <url>.

Without the forge

These work today, in eu1 too:

• A local session. ciresk dev up syncs your worktree into the session, and you pull, commit and push in your worktree with your own git. This is the way to get edits into git from Ciresk's cloud today.
• Checkpoints. ciresk dev checkpoint saves a remote session's workspace as a tree root and prints it, with the next step to run Ciresk CI on it (ciresk ci check --tree <root>).
• Stopping and continuing. ciresk dev stop checkpoints a remote session and releases its compute; ciresk dev start, or ciresk dev up --remote after the session ended, continues it from its last checkpoint.

For operators of an installation

The forge is a setting of the installation, not of your organization. It is off until the operator sets it on the hosts that run sessions:

A value that does not configure is logged at start and leaves pushes off.

The installation's egress.yaml names its rows by product, and three products concern dev:

Turning push on means the variables above plus dev-push rows for the forge's hosts: with GitHub, github.com and api.github.com; with an ssh forge, the git server's host. Without the API row the pull request calls are refused and answer forge_unavailable. Never list the forge for dev-session instead: that opens it to every session's own traffic.