Skip to content

CLI: --no-repo still initializes default virtual repo #4316

Open

Description

@sachintandon

Summary

In dstack CLI 0.22.0/0.22.1, dstack apply --no-repo still initializes the default virtual repository and calls POST /api/project/{project}/repos/init.

Reproduction

Run a repo-free task with dstack apply -f task.yml --no-repo -y. The CLI still calls /repos/init; on a project where the caller cannot initialize repositories, apply fails with 403.

Cause

In src/dstack/_internal/cli/services/configurators/run.py, get_repo() returns None when configurator_args.no_repo is set, but get_plan() unconditionally creates the default virtual repo:

repo = self.get_repo(conf, configuration_path, configurator_args)
if repo is None:
    repo = init_default_virtual_repo(api=self.api)

Proposed fix

repo = self.get_repo(conf, configuration_path, configurator_args)
if repo is None and not configurator_args.no_repo:
    repo = init_default_virtual_repo(api=self.api)

Expected behavior

  • With --no-repo, do not call /repos/init and submit the run without a repo.
  • Without --no-repo, preserve the current default virtual repo behavior.
  • Add a CLI regression test asserting init_default_virtual_repo() is not called when no_repo=True.

Activity

  1. peterschmidt85 commented on Sep 25, 2026

    @peterschmidt85
    Contributor
  2. sachintandon commented on Oct 6, 2026

    @sachintandon
    Author

    @un-def / @peterschmidt85 any update on it ?

  3. peterschmidt85 commented on Oct 7, 2026

    @peterschmidt85
    Contributor

    @sachintandon We look into this and it seems the problem is not with /repos/init at all. The real problem is that you dstack CLI is either using an invalid dstack token or a valid dstack token is used with a project where the user is not a member.

    The /repos/init API is failed only because it's invoked before other APIs are called. Even if this API is not called, another API, e.g. runs/get_plan would fail with the same 403 error.

    The situation is simply that any dstack command will fail, including dstack ps, dstack offer, dstack fleet, etc.

    For example, if you configure your dstack token via dstack project add (in ~/.dstack/config.yml), and you call dstack project -v, you'll see something like this:

    dstack project -v                                                                                                                                                                                   ─╯
     PROJECT           URL                          USER             DEFAULT
     peterschmidt85    https://sky.dstack.ai        (invalid token)  ✓
    

    Means the specified dstack token doesn't give you the access to the specified project.

    You can also check it via dstack UI:

    1. Open dstack UI, go to your user Settings and check Token. If you're using a wrong token in CLI, re-configure the CLI with dstack project add.
    2. Then open the specified project Settings, and check that your user is listed as a member of that project. If not, ask the project admin, to add your user.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions