services/runner/src · flagon-io/g1t

backup.test.tsMerge branch 'worktree-agent-ac5b181a013e54348'1w ago

backup.tsMerge branch 'worktree-agent-ac5b181a013e54348'1w ago

broker-egress.tsMerge brokered secrets: a secret a job uses only to call an API can be tied to the hosts it is for, and the job gets a stand-in in its place, which g1t fills in on the way out to those hosts and nowhere else, so the value never enters the sandbox; and a request to an allowed host that fails upstream is retried when it can be, or answered with a 502 that says why, rather than reset.2d ago

broker-relay.test.tsBrokered secrets work on self-hosted runners whose jobs run on Linux or macOS, and the value still never reaches the runner's computer. The job keeps its stand-in; a harness that can broker says so when it fetches its spec (`broker`), and the spec then lists each stand-in's hosts (`brokered`), never a value. The harness runs a proxy for the job on 127.0.0.1 and gives the steps HTTPS_PROXY, NODE_USE_ENV_PROXY and the trusted-certificate variables g1t's own sandboxes set (SSL_CERT_FILE, NODE_EXTRA_CA_CERTS, REQUESTS_CA_BUNDLE, CURL_CA_BUNDLE, PIP_CERT, GIT_SSL_CAINFO, CARGO_HTTP_CAINFO), each pointing at what it pointed at before with the job's certificate added. HTTPS to any other host is a plain tunnel. HTTPS to a brokered host is opened with a certificate from an authority made for that job alone, name-constrained to the brokered hosts and with its key only in memory; each request on it that carries one of the job's stand-ins goes to POST /actions/jobs/{job}/broker with the job's current token in Authorization, and a request without one goes straight to the host on a connection of its own.2d ago

broker-relay.tsBrokered secrets work on self-hosted runners whose jobs run on Linux or macOS, and the value still never reaches the runner's computer. The job keeps its stand-in; a harness that can broker says so when it fetches its spec (`broker`), and the spec then lists each stand-in's hosts (`brokered`), never a value. The harness runs a proxy for the job on 127.0.0.1 and gives the steps HTTPS_PROXY, NODE_USE_ENV_PROXY and the trusted-certificate variables g1t's own sandboxes set (SSL_CERT_FILE, NODE_EXTRA_CA_CERTS, REQUESTS_CA_BUNDLE, CURL_CA_BUNDLE, PIP_CERT, GIT_SSL_CAINFO, CARGO_HTTP_CAINFO), each pointing at what it pointed at before with the job's certificate added. HTTPS to any other host is a plain tunnel. HTTPS to a brokered host is opened with a certificate from an authority made for that job alone, name-constrained to the brokered hosts and with its key only in memory; each request on it that carries one of the job's stand-ins goes to POST /actions/jobs/{job}/broker with the job's current token in Authorization, and a request without one goes straight to the host on a connection of its own.2d ago

broker.test.tsA brokered secret is filled in only over HTTPS. A job's request to one of the secret's hosts over plain HTTP would have carried the real value across the internet readable by anyone on the way; it now goes with the stand-in, and the job's log notes it once, as for a host the secret is not for. The secrets guide says so.2d ago

broker.tsA brokered secret is filled in only over HTTPS. A job's request to one of the secret's hosts over plain HTTP would have carried the real value across the internet readable by anyone on the way; it now goes with the stand-in, and the job's log notes it once, as for a host the secret is not for. The secrets guide says so.2d ago

bump.test.tsTeams and CODEOWNERS, labels and milestones, dependency updates, the security suite, and a clearer top bar6d ago

bump.tsTeams and CODEOWNERS, labels and milestones, dependency updates, the security suite, and a clearer top bar6d ago

computer-shape.tsEvery agent can have its own computer. A session that needs one wakes it: a home of its own on g1t cloud, one per agent and never shared, where it runs commands, reads and writes files and keeps what it made, with each session working in its own folder under a shared home; after ten idle minutes it sleeps, its home kept as a snapshot and restored when it wakes, and Reset wipes the home while memory and artifacts stay. Its shell and files are abilities with the usual choices, Alone, Alone when asked, Ask first or Never, offered only inside sessions and never to a chat reply; every command shows on the session with its output, and the agent's new Computer tab shows the state, the disk used of the five gigabytes included, the recent commands, and Wake, Put to sleep and Reset. Machine time counts only while it is awake, on the sandbox lines of the ledger that name the agent and who asked, held to the same spend caps as the session; the disk itself costs nothing in this version. The runner gained a long-lived supervisor that answers the computer's requests inside the container, and the runner service a computer per agent that keeps its snapshot in the agent homes bucket when one is attached, and says so when none is. The REST API and the agent tool can read a computer, wake it, put it to sleep and reset it. The agents, abilities, sessions, runners, billing and deploy guides say how it works and what an operator sets up; pinning a computer to your own runner, its browser and take-over come next.3d ago

computer.test.tsEvery agent can have its own computer. A session that needs one wakes it: a home of its own on g1t cloud, one per agent and never shared, where it runs commands, reads and writes files and keeps what it made, with each session working in its own folder under a shared home; after ten idle minutes it sleeps, its home kept as a snapshot and restored when it wakes, and Reset wipes the home while memory and artifacts stay. Its shell and files are abilities with the usual choices, Alone, Alone when asked, Ask first or Never, offered only inside sessions and never to a chat reply; every command shows on the session with its output, and the agent's new Computer tab shows the state, the disk used of the five gigabytes included, the recent commands, and Wake, Put to sleep and Reset. Machine time counts only while it is awake, on the sandbox lines of the ledger that name the agent and who asked, held to the same spend caps as the session; the disk itself costs nothing in this version. The runner gained a long-lived supervisor that answers the computer's requests inside the container, and the runner service a computer per agent that keeps its snapshot in the agent homes bucket when one is attached, and says so when none is. The REST API and the agent tool can read a computer, wake it, put it to sleep and reset it. The agents, abilities, sessions, runners, billing and deploy guides say how it works and what an operator sets up; pinning a computer to your own runner, its browser and take-over come next.3d ago

computer.tsAn archived agent can be found, brought back, or deleted for good. The Agents page ends with Archived, folded, where owners see every archived agent and members their own personal ones, each with when and by whom it was archived and what deleting it would take; Restore brings it back, under a new handle when a live agent has taken its old one, and Delete permanently asks for the handle to be typed and then removes its sessions, replies, memories, routines, versions, drafts, skills and its computer's home, leaving its messages in chat under its saved name, the workspace's spend totals and the audit log. In Chat an archived agent is deactivated the way people expect: never offered as someone to message or mention, never woken, a conversation with it kept in the list, dimmed and marked Archived, open to read with a note in place of the composer and a way to restore it for owners; after deletion the conversation still reads, its messages marked as a deleted agent's. The agents, chat and agent budgets guides say so.3d ago

credentials.test.tsMerge platform pause and the hourly usage watcher: staff can pause compute, schedules, indexing or renders for everyone, the watcher emails on a breach and is never blind quietly, and the models proxy holds each run to its cap (billing 0051, integrations 0006)5d ago

credentials.tsMerge platform pause and the hourly usage watcher: staff can pause compute, schedules, indexing or renders for everyone, the watcher emails on a breach and is never blind quietly, and the models proxy holds each run to its cap (billing 0051, integrations 0006)5d ago

delegate.test.tsIntegrations are a directory of connectors, for a workspace and for each person5d ago

delegate.tsIntegrations are a directory of connectors, for a workspace and for each person5d ago

egress.test.tsMerge branch 'runner-egress-reset'2d ago

egress.tsMerge branch 'runner-egress-reset'2d ago

forward.test.tsnpm installs on g1t's cloud runners stop failing with "network aborted". The upstream sometimes broke off in the middle of a tarball's body, after its headers had already been handed to the sandbox, so the retry added for failed requests couldn't help: npm got a truncated file and gave up. Now an answer to a request that can be sent again (a GET or HEAD with no body), of known length up to 8 MB and sent uncompressed, as package tarballs are, is read whole by the runner Worker before the sandbox gets it; one whose body breaks off is tried again, twice, and still failing becomes a 502 saying why, never a truncated answer. Larger answers and ones of unknown length stream as before. And the repository's installs open at most 8 connections at once rather than npm's 15, since each passes through the Worker and bursts of parallel downloads were when it happened.2d ago

forward.tsnpm installs on g1t's cloud runners stop failing with "network aborted". The upstream sometimes broke off in the middle of a tarball's body, after its headers had already been handed to the sandbox, so the retry added for failed requests couldn't help: npm got a truncated file and gave up. Now an answer to a request that can be sent again (a GET or HEAD with no body), of known length up to 8 MB and sent uncompressed, as package tarballs are, is read whole by the runner Worker before the sandbox gets it; one whose body breaks off is tried again, twice, and still failing becomes a 502 saying why, never a truncated answer. Larger answers and ones of unknown length stream as before. And the repository's installs open at most 8 connections at once rather than npm's 15, since each passes through the Worker and bursts of parallel downloads were when it happened.2d ago

gate.test.tsMerge GitHub pull request #8 (claude/cool-newton-7nm8r9): Docker deployments on g1t.page behind a switch that stays off until Cloudflare's container APIs are checked live, workflows a workspace manages in its repositories, tarball and zipball downloads, refs/pull/* kept to g1t alone, framework detection for g1t.page builds, and a workflow's event payload matching GitHub's.2d ago

guard.tsMerge brokered secrets: a secret a job uses only to call an API can be tied to the hosts it is for, and the job gets a stand-in in its place, which g1t fills in on the way out to those hosts and nowhere else, so the value never enters the sandbox; and a request to an allowed host that fails upstream is retried when it can be, or answered with a 502 that says why, rather than reset.2d ago

hosted.test.tsGit storage hardened, pages in tens of milliseconds, honest security alerts, and costs reconciled daily1w ago

hosted.tsGit storage hardened, pages in tens of milliseconds, honest security alerts, and costs reconciled daily1w ago

hub.tsInvite-only launch: sign in with GitHub, repository access and lifecycle, many emails, a new look1w ago

index.tsBrokered secrets work on self-hosted runners whose jobs run on Linux or macOS, and the value still never reaches the runner's computer. The job keeps its stand-in; a harness that can broker says so when it fetches its spec (`broker`), and the spec then lists each stand-in's hosts (`brokered`), never a value. The harness runs a proxy for the job on 127.0.0.1 and gives the steps HTTPS_PROXY, NODE_USE_ENV_PROXY and the trusted-certificate variables g1t's own sandboxes set (SSL_CERT_FILE, NODE_EXTRA_CA_CERTS, REQUESTS_CA_BUNDLE, CURL_CA_BUNDLE, PIP_CERT, GIT_SSL_CAINFO, CARGO_HTTP_CAINFO), each pointing at what it pointed at before with the job's certificate added. HTTPS to any other host is a plain tunnel. HTTPS to a brokered host is opened with a certificate from an authority made for that job alone, name-constrained to the brokered hosts and with its key only in memory; each request on it that carries one of the job's stand-ins goes to POST /actions/jobs/{job}/broker with the job's current token in Authorization, and a request without one goes straight to the host on a connection of its own.2d ago

instructions.test.tsAgents get guardrails, run credentials, an audit log, a context hub, repository instructions and mentions; security upkeep; snake_case API1w ago

instructions.tsg1t is one name: its agent's work, commits and comments show as @g1t, and nobody can claim g1t or g1t-agent1w ago

lifecycle.test.tsMerge remote-tracking branch 'origin/main' into workspace-chat5d ago

lifecycle.tsMerge remote-tracking branch 'origin/main' into workspace-chat5d ago

mentions.test.tsMerge branch 'worktree-agent-ad8a36dfcd4176015' into spend-guardrails5d ago

mentions.tsMerge branch 'worktree-agent-ad8a36dfcd4176015' into spend-guardrails5d ago

model-defaults.test.tsMerge branch 'main' into actions-toolkit-oidc-artifacts6d ago

model-env.test.tsMerge branch 'main' into worktree-agent-a69aeabc4b0deeb976d ago

model-env.tsMerge branch 'main' into actions-toolkit-oidc-artifacts6d ago

repo-instructions.tsAgents get guardrails, run credentials, an audit log, a context hub, repository instructions and mentions; security upkeep; snake_case API1w ago

self-hosted.test.tsThe Runners page shows the machines a workspace's agents and workflow jobs run on, in Workspace under Compute: g1t's cloud beside your own runners, what each is running now with a link to it, what's waiting, this month's machine time and its cost (your own runners' free), where agent work and workflow jobs run, adding a runner, and groups; runner_activity in Actions says what runs where, work handed to your runners keeps its agent run, and the self-hosted runners guide says how.4d ago

self-hosted.tsThe Runners page shows the machines a workspace's agents and workflow jobs run on, in Workspace under Compute: g1t's cloud beside your own runners, what each is running now with a link to it, what's waiting, this month's machine time and its cost (your own runners' free), where agent work and workflow jobs run, adding a runner, and groups; runner_activity in Actions says what runs where, work handed to your runners keeps its agent run, and the self-hosted runners guide says how.4d ago

workflow-hosts.test.tsFast pages, required checks on the branch, self-hosted runners, honest incidents1w ago