Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

design: one CLI for delegating subagent tasks to Moca

Open
  • Is something wrong?
#495 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
15/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
python, typescript
Domain
ai, cli

Research direction

This is a design decision, not a code task. Read the proposal against remote_task.py from #455, Maia's moca start | check | list demo, and the planned #381 subagent commands, and check how mocactl currently handles login, sessions and promote/bundles. Done means the four open questions have maintainer answers and the design is agreed, not that code is written. Discuss in the thread before building anything.

Written by the indexing model from the issue text.

Description

Why. Today there are three separate clients for the same job:

  1. remote_task.py from #455 (the original context-delegation PR): uploads local files once as a workload's context, then runs many tasks in parallel and waits for each result.
  2. Maia's demo CLI, moca start | check | list (kagenti-demos/sandboxing/moca_chained_subagents). start hands a task to Moca through a background process that holds the request open, so the local agent can quit. check collects the result later, and list shows what's pending.
  3. #381 (planned mocactl subagent commands): spawn, subagents, get, watch, approve, follow-up. It's the same idea as Maia's, plus a local record of spawned tasks.

mocactl today has login, run (interactive turns), sessions, credentials and promote/bundles (config bundles). We should agree on one client before building more.

Proposal

  • mocactl is the client. It already handles login, server URLs and sessions.
  • #381's commands with Maia's proven behavior: a background worker holds each run open, the result is written to disk, and /runs/status is used only to recover a result if the worker died.
  • Context is an option on a task: mocactl spawn --workload <id> "prompt" runs the task with that workload's files (#494, run tasks on a workload's context).
  • Workloads are set up separately: mocactl workloads create --context <file> uploads a context file made by contextctl ctx export, and mocactl workloads delete <id> cleans up. mocactl never calls contextctl itself.
  • Fan-out is many spawn calls under a concurrency limit. There's no separate batch command.
  • Naming: mocactl already uses "bundle" for config bundles, so uploaded context is called a context in the CLI, never a bundle.

Open questions

  1. Is mocactl workloads … the right place for workload setup?
  2. Should the delegate skill call mocactl directly, or a thin wrapper whose permission prompts read clearly (Maia's Bash(moca start*) pattern)?
  3. What should watch print so hundreds of tasks stay readable in Claude Code's Monitor tool?
  4. Once this exists, should Maia's demo switch to mocactl?

Not in scope: server changes, and per-workload sandboxes, which are #476 (phase 2: per-workload sandboxes and storage).

cc @pdettori @maia-iyer @evaline-ju

Dominant language
TypeScript
Stars
4
Forks
9
Avg merge
9h 31m
Merged PRs (30d)
139

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from rossoctl/moca

All issues in rossoctl/moca

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.