---
title: "Work from another directory"
url: "https://docs.alisx.com/how-to/cli/work-from-another-directory/"
---
# Work from another directory

Run `alis` against a service or product without changing your shell's directory, and let the CLI fill in package IDs and references from where it runs.

## Prerequisites

- A product cloned under `~/alis.build/<org>/build/<product>/` (`alis clone <org>.<product> --json` does this).

## Steps

1. See what the CLI resolves from a directory:

    ```bash title="Terminal"
    alis --cwd ~/alis.build/acme/build/shop/orders/v1 context view --json
    ```

    ```json
    {"organisation": "acme", "product": "shop", "packageId": "acme.shop.orders.v1", "serviceFolder": "…", "defineFolder": "…", "environments": [{"id": "<env-id>", "displayName": "Development", "production": false, "status": "ACTIVE", "projectId": "<project-id>"}]}
    ```

    `--cwd` is a global flag: it runs the command in that directory without a shell `cd` and without changing your parent shell. Coding-agent tools that cannot change directory use it on every call.

2. Omit the package ID inside a service folder. These are equivalent:

    ```bash title="Terminal"
    alis build acme.shop.orders.v1 --json
    alis --cwd ~/alis.build/acme/build/shop/orders/v1 build --json
    ```

3. Omit the leading parts of a dot reference inside a product folder. References fill right-aligned:

    ```bash title="Terminal"
    alis --cwd ~/alis.build/acme/build/shop product view --json          # acme.shop
    alis --cwd ~/alis.build/acme/build/shop environment refresh <env-id> --output .alis/.env   # acme.shop.<env-id>
    ```

4. Pass the full reference when you are outside `~/alis.build`:

    ```bash title="Terminal"
    alis --cwd /tmp context view --json
    ```

    ```json
    {"notes": ["no local context — run inside ~/alis.build/<org>/build/<product> or pass <org>.<product>"]}
    ```

    ```bash title="Terminal"
    alis context view acme.shop --json
    alis build acme.shop.orders.v1 --json --branch main
    ```

## How a package ID maps to folders

`acme.shop.orders.v1` maps to the implementation folder `~/alis.build/acme/build/shop/orders/v1`, the definitions folder `~/alis.build/acme/define/acme/shop/orders/v1`, and the service id `orders-v1`. Multi-segment paths work the same way: `acme.shop.internal.api.v2` is `internal/api/v2`.

## Commits are detected too

`define` uses the latest pushed commit of the definitions repo; `build` uses the latest pushed commit that touched the service folder on the checked-out branch. Push first. In automation, pass `--branch <branch>` explicitly; a detached checkout must.

## Inside a workstation

The CLI is locked to the workstation's organisation. A command for another organisation fails with exit 1 rather than resolving elsewhere; `alis workstation open <org>` opens that organisation's workstations instead.

Related: [alis context](https://docs.alisx.com/reference/cli/context.md), [Organisations, products and services](https://docs.alisx.com/explanation/organisations-products-services.md).