> ## Documentation Index > Fetch the complete documentation index at: https://docs.mirurobotics.com/llms.txt > Use this file to discover all available pages before exploring further. # Get Current > Retrieve the current release. ## OpenAPI ````yaml /references/device-api/v0.2.2/api.yaml get /releases/current openapi: 3.0.3 info: title: Miru Agent API description: >- The API between the Miru Agent and any external client living on the same device as the Miru Agent version: v0.2 license: name: MIT url: https://opensource.org/licenses/MIT x-release-version: v0.2.2 x-git-commit: sha: 97aec4ae3541349ead148f90acedb59b0f543fdb url: >- https://github.com/mirurobotics/openapi/commit/97aec4ae3541349ead148f90acedb59b0f543fdb message: |- docs(stlc): how to change SDK custom code (#307) ## Why Hand-written SDK code goes back to stlc's intended flow (upstream docs: "Custom code" and "Branching and collaboration"): 1. Edit the code in a local checkout of the staging SDK repo. 2. Seal it with `stlc build`. 3. Merge the tracking file through a PR here. A tracking file shows only two commit IDs, so the code itself needs somewhere to be reviewed. That's why we tried merging PRs into the staging repos (mirurobotics/infra#294), which stlc doesn't support. mirurobotics/python-device-sdk-staging#3 needed a manual re-seal (#305), and mirurobotics/infra#299 turns those merges off again. This PR documents the flow, with the review happening in a **review-only PR on the staging repo**. ## What New `docs/sdk-custom-code.md`, linked from the README: - **What custom code is:** what tracking files hold and how stlc applies them. - **Rules:** - nothing merges into staging `main`; PRs there are for review only; - prefer config over code; - put new code in `src//lib/`. - **Steps:** 1. `stlc build` to get the local checkout. 2. Commit on a `custom-code/` branch from staging `origin/main`, so the diff is only the change. 3. Open a review-only PR on the staging repo. GitHub shows the change and the AI review runs. 4. Cherry-pick the commit onto local `main` and `stlc build` to seal it. 5. Open the tracking-file PR here, linking the staging PR, and close the staging PR after it lands. An earlier version of this PR added a CI job that commented the custom-code diff here. It's removed in favour of reviewing in the SDK repo, so the PR is now docs only. ## Depends on mirurobotics/infra#299. Until it's applied, a review PR on `python-device-sdk-staging` could still be merged, which is the situation #305 had to repair. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 author: ben-miru branch: HEAD dirty: false x-build: built_at: '2026-10-09T18:04:19.383464+00:00' servers: - url: http://localhost/v0.2 description: localhost security: - {} - BearerAuth: [] paths: /releases/current: get: tags: - Releases summary: Get Current description: Retrieve the current release. operationId: getCurrentRelease responses: '200': description: Successfully retrieved the current release. content: application/json: schema: $ref: '#/components/schemas/Release' x-codeSamples: - lang: curl label: curl (Linux) source: |- curl \ --unix-socket /run/miru/miru.sock \ --request GET \ --url http://localhost/v0.2/releases/current - lang: powershell label: PowerShell (Windows) source: >- $api = Get-Content -Raw "$env:ProgramData\Miru\device-api\device-api.json" | ConvertFrom-Json; ` Invoke-RestMethod -Method Get ` -Uri "http://127.0.0.1:$($api.port)/v0.2/releases/current" ` -Headers @{ Authorization = "Bearer $($api.token)" } - lang: Python source: |- from miru_device_sdk import Miru client = Miru() release = client.releases.current() print(release.id) components: schemas: Release: title: Release type: object required: - object - id - version - git_commit_id - file_rule_ids - os - created_at properties: object: type: string enum: - release example: release x-stainless-const: true description: The object type, which is always `release`. id: type: string example: rls_123 description: ID of the release. version: type: string example: v1.0.0 description: The version of the release. git_commit_id: type: string nullable: true example: git_commit_123 description: The ID of the git commit associated with this release. file_rule_ids: type: array items: type: string example: - file_rule_123 description: >- IDs of the file rules included in this release. Retrieve each file rule with `GET /file_rules/{file_rule_id}`. os: allOf: - $ref: '#/components/schemas/OS' readOnly: true description: >- The operating system family this release targets, derived from its config schemas and file rules, which must all agree. A release with neither is `linux`. Read-only: clients cannot set it. created_at: type: string format: date-time example: '2024-01-01T00:00:00Z' description: Timestamp of when the release was created. example: object: release id: rls_123 version: v1.0.0 git_commit_id: git_commit_123 file_rule_ids: - file_rule_123 os: linux created_at: '2024-01-01T00:00:00Z' OS: title: OS type: string description: > An operating system family, from the agent's build-time OS vocabulary. Shared across resources (devices, config schemas, file rules, releases). This is the machine-readable OS kind, distinct from a human-readable version string. - `linux` - `windows` example: linux enum: - linux - windows x-enum-varnames: - OS_LINUX - OS_WINDOWS securitySchemes: BearerAuth: type: http scheme: bearer description: >- The token from the agent's discovery file. Required over loopback TCP; not used over the Unix socket. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.