Points the runtime image at the development repository on Docker Hub, so
'apify runtime install' downloads it instead of expecting a locally built
placeholder. Reworks the pull-failure hint accordingly.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Mpiku6d313JRBVoTVKNCXv

Co-authored-by: Claude <noreply@anthropic.com>

Co-authored-by: Claude <noreply@anthropic.com>

Update the CLI to accept both Docker or Podman.

---------

Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>

Actors running through local actor runtime will by default work in local
dev folder mode.

Depends on: apify/actor-runtime#43

---------

Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>

`apify runtime install [image]` pulls the given image instead of the
default `apify/actor-runtime:latest`, so a pinned build or another
runtime implementation can be used:

```sh
apify runtime install apify/actor-runtime:master-5462005
```

- The installed image is recorded in
`~/.apify/actor-runtime/config.json`.
- `apify runtime start` runs whatever was installed last; no flags or
checks there.
- Without an argument, `install` keeps using the default image.
- No new dependencies.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

https://claude.ai/code/session_01U7Bi6BtaXTmLFxAiV3gRZ3

Co-authored-by: Claude <noreply@anthropic.com>

'apify runtime status' reports whether the runtime container is running,
on which engine and image, the ports it publishes, the host directory
mounted as its data directory, and which API the CLI currently targets.
It exits 1 when the runtime is down, and takes --json.

'apify runtime connect' makes every CLI command target the local
runtime, and 'apify runtime disconnect' reverts to the Apify platform.
The connection is stored next to the installed image in
~/.apify/actor-runtime/config.json, so it holds across terminals and
does not touch the login. APIFY_CLIENT_BASE_URL and APIFY_CONSOLE_URL
keep taking precedence wherever they are set, so the current per-shell
behavior is unchanged; both commands say so when they are set.


Claude-Session: https://claude.ai/code/session_01PaySaAvWxMBNuVMSXXLqno

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

Adds `apify runtime skill [--install]`, which reads the runtime's own
Agent Skill over HTTP when the runtime is running, or straight out of
the installed image when it is not — so `apify runtime install` is the
only prerequisite.

No copy is bundled with the CLI: one could only ever describe the image
the CLI was released against. `runtime install`, `start`, `connect` and
`status` now print one line pointing at the command.

Refs apify/actor-runtime#53. Needs apify/actor-runtime#54 to land first,
since the image must carry the file.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

https://claude.ai/code/session_01ExpRUXDzyTmT828ugqkjAP

---------

Co-authored-by: Claude <noreply@anthropic.com>

…t updated (#1448)

`apify runtime install` no longer skips the pull when the image exists
locally, so an outdated `apify/actor-runtime:latest` gets updated from
the registry.
Only `@sha256:` digests short-circuit; `apify runtime start` still uses
the local copy.

---------

Co-authored-by: Claude <noreply@anthropic.com>

…time (#1463)

`apify push` no longer prints the dev-folder success notice; the runtime
now logs it in the build log (needs apify/actor-runtime counterpart).

Co-authored-by: Claude <noreply@anthropic.com>

…art' (#1465)

- `apify runtime start --api-port/--console-port` runs the Actor runtime
on other ports; they are remembered for later starts, `connect`,
`status`, `skill` and console links in `apify call`.
- Ports are ignored while disconnected, so platform traffic is
unaffected. Default ports keep older runtime images working.
- Needs apify/actor-runtime#80 for non-default
ports. No new dependencies.

---------

Co-authored-by: Claude <noreply@anthropic.com>

- `apify push` of an Actor whose `.actor/actor.json` sets
`dockerContextDir` sends its Git repository, as the platform's clone
would have it, to the local Actor runtime (apify/actor-runtime#89), with
the Actor's path in it.
- Files: tracked ones as on disk plus untracked ones Git doesn't ignore,
symlinks kept, no `.actorignore`; uncommitted changes are pushed with a
warning.
- A `dockerContextDir` outside the Git repository is rejected; the
Docker context is registered as the dev folder.
- Against the Apify platform, such a push stops with an error linking
apify/apify-core#28685.
- No new dependencies (uses the existing `archiver`).

---------

Co-authored-by: Claude <noreply@anthropic.com>

… Podman 3.x (#1485)

- `apify runtime start` adds `--network
slirp4netns:allow_host_loopback=true` on rootless Podman 3.x, read from
one `podman info` call; every other engine keeps the plain command.
- Why: the runtime reaches the web servers of the runs it starts (their
`containerUrl`, apify/actor-runtime#91) through that route; without it
only standby runs' servers are reachable there.

Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>

Resolves conflicts with the auth rework on master (profiles, getCurrentUserInfo,
client options moved to auth.ts):

- route the API base URL through resolveApiBaseUrl() in auth.ts, outputJobLog
  and the rental sunset notice, so `apify runtime connect` still applies
- call/push use getCurrentUserInfo(); push keeps the monorepo docker context
- runtime test mocks follow the getCurrentUserInfo rename
- regenerate docs/ for the merged flag sets

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015JzfLYa5CHCXxfzC1No3gV

…s 3333 (#1490)

## What

- `apify login` with a local Console URL always validated the token
against `http://localhost:3333`, so a runtime started on another port
(`apify runtime start --api-port 4333`, or `ACTOR_RUNTIME_API_PORT` from
apify/actor-runtime#80) was unreachable from login.
- Login now picks the API in this order: `APIFY_CLIENT_BASE_URL` or the
connected runtime, then the port the runtime was last started on, then
3333 when no port is known (hand-started runtime on the defaults, local
platform development).
- Adds `resolveLoginApiBaseUrl()` with unit tests for each of those
cases.

## Verified

- Against a real `apify/actor-runtime:latest` started with `--api-port
4333 --console-port 4000`: login succeeds while connected, and with only
`APIFY_CONSOLE_URL=http://localhost:4000` set, with nothing listening on
3333.
- Lint, format, build, and `test:local` (the only failures are the
pre-existing root-user "cannot write" cases).

Co-authored-by: Claude <noreply@anthropic.com>

## What

The CI probe [#1493](#1493)
showed `Local Tests (windows-2025)` red on `actor-runtime` because two
branch-only tests assume POSIX paths and modes. The CLI code is fine on
Windows; only the assertions were wrong.

- `test/local/lib/runtime-source-context.test.ts`: expected roots were
built with `join('/repo')`, which is `\repo` on Windows, while
`resolveDockerContext` uses `resolve()` and gets `D:\repo`. The test now
resolves the same way.
- `test/local/commands/push-monorepo.test.ts`: the tarball mode
assertion expected `0o755` after `chmod`, but Windows has no execute
bit, so the archive records `0o666`. That one assertion is skipped on
Windows, as the existing mode tests in `auth-file` and `credentials`
already do; the rest of the test still runs there.

Test-only change; no CLI behavior changes.

Co-authored-by: Claude <noreply@anthropic.com>

…esktops (#1495)

Two cases where `apify runtime start` produced a runtime that reported
the engine as unavailable. Both surfaced on actor-runtime's macOS CI leg
([apify/actor-runtime#65](apify/actor-runtime#65)).

**SELinux on Podman hosts**
- Under SELinux enforcing (Fedora, RHEL, and the Fedora-based VM of
`podman machine`, so Podman Desktop on macOS and Windows), the runtime
container may not connect to the engine's API socket bind-mounted into
it: the socket carries the engine's label, not a container's.
- `podmanInfo` now also reads `Host.Security.SELinuxEnabled`;
`buildRuntimeRunArgs` adds `--security-opt label=disable` via the new
`runtimeSecurityOptions`, next to `runtimeNetworkMode`.
- Only the runtime container runs unconfined. The Actor containers it
starts stay confined (verified by actor-runtime's dev-folder e2e under
enforcing SELinux).

**Docker socket on macOS and Windows**
- The daemon lives in a VM there and serves `/var/run/docker.sock`
inside it on every desktop engine. A `DOCKER_HOST` unix socket is a host
path (Colima's docs suggest exporting one for tools that ignore
contexts), which a bind mount cannot carry into the VM.
- `resolveEngineSocketPath` now consults `DOCKER_HOST` only on Linux.

---------

Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>