cMeta AOPS v0.65.2: stable release

• cx host ls shows the Python each host's cx runs on, next to cMeta and AOPS (the user, 2026-11-06): a column
  PYTHON - "3.14.7", "3.15.2t" for a free-threaded build (no GIL) - for the host and for each of its projects (a
  server's own environment), and in the project line of cx host status ("Python: ..."). The probe records it
  (cmeta_python in state.yaml; probe.sh and probe.ps1 ask the interpreter that cx --version names for its
  version), so it appears after the next cx host probe; "-" until then. Why: the Python decides how a server's
  workers start (cMeta 0.38.11: forkserver on Linux up to 3.13 too, where Python's own default was fork), and the
  night of 2026-11-05/06 showed the fleet runs five different ones. The backup record keeps it with the other
  versions. Test: tests/cmeta_aops_basic_tests/test_host_table_projects.py (the column aligned for a host and its
  projects, "-" for a project never probed).

cMeta AOPS v0.65.1: stable release

0.65.1

• Every config key cmeta-aops reads is described - for the engine's page /cmeta.configs (cMeta 0.38.7), which
  listed keys that tasks, tools and categories read without saying what they do. Each now has a description,
  written from the code that reads it, in a configs: block of the reader's _desc.yaml: run-ai (default:
  run_ai_max_context_tokens; the config task-run-ai, this machine's settings of run-ai), set-ai-gateway
  (default: run_ai_gateway, run_ai_gateway_name, run_ai_gateway_<harness>), get-host--docker and
  get-host--wsl (task: cmeta_version; task-get-host--wsl: location), compile-and-run-program (task:
  compile_and_run_program.skip_cache), test-session (task: test_session.*), test-on-hosts
  (task-test-on-hosts: hosts, here_dir), tool/hf (task: hf.cache); the keys a whole category reads, in a
  new _desc.yaml of the category: task (use, tool.check_versions, cache_repos.<key>, cache_repos.data),
  tool (winget_install_flags), container (engine, cmeta_local_path; the config a container command names
  with --secret=<alias>, whose every key is a secret for the template's build or run). The examples are values,
  as the page builds its "set it" line from them; the types are the page's words (yes/no, dict).
  cx cserver.cmeta.configs list "repo:ctuninglabs@cmeta-aops is:undocumented" lists nothing now.
• tool/codex: the model list of 2026-11-04 (gpt-6.1-terra with its efforts; the ChatGPT models page among
  the sources).

cMeta AOPS v0.65.0: stable release

See https://github.com/cTuningLabs/cmeta-aops/blob/main/CHANGELOG.md#0650 .

cMeta AOPS v0.64.1

cMeta AOPS v0.64.1 - see the CHANGELOG section 0.64.1.

• run-ai --record_prompt: the text submitted to the harness is kept as !AI/log/<stamp>.<harness>.prompt.md and the run answers with prompt_file; off by default, nothing with --no_log.

cMeta AOPS v0.64.0

cMeta AOPS v0.64.0 - see the CHANGELOG section 0.64.0.

• A token kept with a password and given to one command alone: cx secret store <alias> [--password_protected] (a hidden prompt; standard library only: scrypt keys, an HMAC-SHA256 key stream and tag), cx secret run <alias> --env.<NAME>={secret} -- <command> (the value in that command's environment and nowhere else; on Windows a console window of its own for the password when the caller has no terminal), cx secret check --unlock.
• tool/twine (7.0.0 in its own Python 3.12 environment) and the task upload-to-pypi: twine check, then twine upload --non-interactive with TWINE_PASSWORD from --secret=<alias> or the one token secret that declares service: pypi.
• cx secret ls and cx ai.gateway ls show their own tables (the engine turns ls into list before it looks for a command).

cMeta AOPS v0.63.1

0.63.1

• run-ai keeps what a session really ran with: run_ai_config.last_seen. A run without --model leaves the
  choice to the harness, and the project never knew it; after a Claude Code or Codex run, the model and the effort of
  the session's last reply (read from the end of its own file) go into run_ai_config.last_seen with the time, the
  next run shows them ("no model given: the harness picks its own - its last run here ran ...") and never passes them
  on. Written when the harness, the model or the effort changed; a rewrite of the block keeps it. Tests:
  test_run_ai_config.py, test_run_ai_conversations.py.
• The generator record of an agent session no longer names its AI gateway. run-claude and run-codex put
  gateway: <alias> into CMETA_GENERATOR, so every artifact an agent made through a gateway recorded the alias
  in its _cmeta - in public repositories too, where an alias may name an organisation; the record names the
  agent and its version, the run's own log keeps the gateway. The records of eleven artifacts here lost the key;
  a changelog line, a comment and a test fixture got neutral names.
• cx host upgrade --version=X: a host that ends on another version failed. A host that declares its own
  cmeta: upgrade command runs it as written, so the version did not reach it, and the round said "already "
  as a success (a WSL distro's pip install -U cmeta met pip's cached view of PyPI right after a release). Now such
  a host reads asked X, has Y, counts as failed and is not restarted, and a warning says beforehand when a declared
  command does not name the version (also in --dry-run). Tests: test_host_upgrade_version.py.

cMeta AOPS v0.63.0

0.63.0

• run-ai: a conversation goes on natively on any machine the project is synced to (Claude Code and Codex). Their
  native session files live in the user's home (Claude Code's projects/<slug>/<id>.jsonl and its <id>/ folder,
  Codex's sessions/<date>/rollout-*-<id>.jsonl), so a conversation continued on another machine had to start a new
  native session with the transcript handed over - and for Codex run-ai even tried codex resume <id> there, which
  ended at once with "No saved session found" (the project's Codex SQLite store travels, the rollout did not). Now
  run-ai keeps a copy of the session's files in !AI/sessions/<harness>/ after every run and, before a resume, puts the
  copy back where the harness looks on this machine when the session is missing here or went on elsewhere (the copy
  holds more): the harness resumes it natively. Proven between the laptop and the P14s Gen 4 for both harnesses. A
  Codex session is resumed only where its rollout is; the other harnesses go on with the hand-over as before. Tests:
  test_run_ai_conversations.py.
• run-ai tells the harness where results go: what the user asks to produce (a document, a message, code, data meant
  as part of the artifact) goes into the artifact's own folder or a sub-folder, not into !AI, which keeps the AI's
  own memories, skills, logs and scratch files (a session's final message for the user had landed in !AI).
• A stopped container reads stopped, an engine that does not answer docker engine down. cx host status said
  down for a container that exists and is not running, and missing whether the container was gone or Docker Desktop
  was off; a reader took down for Docker being off and a fleet round left four stopped test containers out
  (2026-11-02). cx host up starts a stopped container as before; the commands that need a running host still skip
  it. missing is now only the engine's own "no such container" (Docker or Podman): the wording of a newer Docker CLI
  with Docker Desktop off ("failed to connect to the docker API at npipe:...") reads docker engine down, and any
  other failure is error: <its first line>, so cx host up never creates a container that may still exist.
  Tests: test_host_docker_status.py.

cMeta AOPS v0.62.0

0.62.0

• The iPhone as a compute target: ios-cpu, ios-gpu, ios-npu. tool/apple.xcode finds Xcode through
  xcode-select (the iOS SDK, the toolchain, devicectl); tool/apple.xcode.clang and -cpp (the apple-xcode
  compiler family) build for the device's architecture, SDK and minimum iOS version. task/target--ios-cpu selects a
  paired iPhone or iPad (--device=<name|UDID>), finds the signing identity, its team and a development profile for
  one bundle id (org.ctuning.cmeta.runner) that provisions the device - made with Xcode's own xcodebuild -allowProvisioningUpdates -allowProvisioningDeviceRegistration when missing, and again when it expires. A
  program for the device gets the target's launcher as its main (it enters the app's Documents folder and records
  the exit code), goes into an app bundle, is signed (through the user's GUI session when an ssh session's keychain
  is locked), installed and launched with devicectl with the console attached; its output files come back
  (category/task/api/ios.py, the iOS branch of setup-run). target--ios-gpu (a Metal probe: the GPU families,
  limits, features) and target--ios-npu (a Core ML probe: the Neural Engine and its cores) ask the device with a
  probe app. test-nmm-c-cpu and lib-xopenme run on ios-cpu (the OpenSSL test skipped there, static archives,
  no OpenMP runtime on iOS yet). Also: a compiler that declares an empty openmp flag builds a program that asks
  for OpenMP without it (an INFO line) instead of failing; the build stamp records the compile parameters as the
  run requested them, before the program's hooks adjust them, and the iOS device's UDID; exe_extra_sources of a
  compiler's target_arch are linked into executables only. Tests: test_ios_target.py.
• A host of type ios: an iPhone or iPad declared with its UDID and the Mac it hangs on (via). cx host status asks that Mac's xcrun devicectl list devices (up when connected, else down (<state>)), cx host probe
  records what devicectl says of it (name, iOS version, model, CPU type, storage, developer mode) in state.yaml, the
  listing shows ios <UDID> via <Mac>; cx host run and restart say that an iOS device runs no command of its own
  (programs reach it through the ios-cpu target). The rows of ls/status carry machine_ref, the declared cRef of
  the host's machine, for pages that link a machine's record. Tests: test_host_ios_device.py.
• cx host run of an adb host no longer lets a command escape to this machine's shell. The command rides inside
  "..." on adb's command line; one that held a double quote of its own - the words after -- that held a space
  arrive quoted - closed that quoting, and its && and | ran HERE (seen on a watch: the part after a | started a
  program of this Windows machine). Such a command (on Linux and macOS also one with $, a backtick or \) now goes
  to the device's sh on stdin from a temporary script, as wsl and docker hosts already did; a plain command keeps
  its one line. host connect hands the reconnect task a copy of the context, so a second host lookup in the same
  call no longer searches the task category ('host "" not found'); a run connects a wireless host once.
• A watch away from home: cx host connect says what to do, and asks. When the address seen before does not
  answer and adb discovery finds nothing (public and office Wi-Fi often block mDNS), the error names the fix -
  --endpoint=IP:port from the MAIN Wireless debugging screen - and in a terminal the command asks for that address
  once and connects (-q keeps the error, no question). Tests: test_wireless_adb_hosts.py.
• cx program run ... android-cpu --use.target--android-cpu.device_host=<host> runs on that device. The task
  framework merges the --use words into a task's parameters after its init, and the Android target chooses its
  device in init: the documented device_host (and serial) never reached it, and with two devices attached a quiet
  run took the first - a run asked for a watch ran on a USB phone, under the watch's build key. The target now reads
  them from the --use words too. A build made that way for the wrong ABI is refused by the strict provenance check
  ("was built for ... asks for armeabi-v7a"); --clean starts it over. Tests: test_wireless_adb_hosts.py.
• Archived hosts: a host kept in a repository whose _cmr.yaml says archive: true leaves every fleet listing.
  cx host ls, status, the fleet commands with --all/--tags and the host pages skip it (a machine given back or
  deleted, moved there with cx host move <host> <repo>:); named exactly it is still found. No repository has the
  flag unless it is added. Tests: test_host_archive_repo.py.

cMeta AOPS v0.61.5

• run-ai --context takes the alias of a declared AI context: an artifact that declares template: ai_uses: {alias, title, sort} in its meta is an AI context (cMeta 0.38.0, 2026-11-02: cx <category> add|update <artifact> -ai, cx utils ai_context); --context=dapple names it as -ai=dapple would, an artifact alias in
  any category works too, a cRef and claude:<folder> as before; an engine without the resolver, or a name it
  cannot resolve, leaves the entry as typed. Test: test_context_aliases_resolve_through_the_engine.

cMeta AOPS v0.61.4

• A framework's own report in --provenance=loaded: after an observed run the recorder asks torch
  (torch.version.cuda, cuDNN, the CUDA devices it sees, MPS), ONNX Runtime (device, providers) and JAX
  (backend, devices) what they report about themselves - through the run's own interpreter by its full
  path, with the run's environment, in the build folder, one process per framework with a 90 s limit -
  and records it under runtime.frameworks[<dist>].reports (the interpreter and the seconds under
  .probe). A torch that reports another CUDA than its wheel was built for, or no CUDA device in a cuda
  run, is a warning (framework); a probe without an answer is a note. on and strict start no process.
  Tests: test_framework_probes_use_the_runs_python, test_framework_report_checks.