## 📝 Summary

Enables running multiple marimo notebook files as a gallery of apps in
the below style:

```shell
marimo run folder
marimo run folder another_folder
marimo run file_a.py file_b.py folder
```

When pointed to a local clone of https://github.com/marimo-team/learn
this gives us:

<img width="1047" height="983" alt="Screenshot 2026-01-29 at 19 24 02"
src="https://github.com/user-attachments/assets/bb6b949c-52f8-4e34-b675-8628e22e0dc4"
/>

Closes #3257 

## 🔍 Description of Changes

I based this work on #4961, borrowing the idea of reusing the existing
home page infrastructure used in `marimo edit` mode and adding `gallery`
as a new frontend view in `marimo run` mode.

- Gallery item links are encoded through `/?file=<encoded>` to avoid
introducing new routing / mounting logic
- Navigation is restricted so that we don't accept arbitrary
`/?file=<encoded>` values
- extended `marimo._server.file_router.ListOfFilesAppFileRouter` to
behave like an allowlist router
- Preserved existing `marimo run app.py -- --arg value` behavior working
while enabling `marimo run file_a.py file_b.py folder` and still
allowing notebook args to be explicitly separated
- Added a root directory heuristic for nicer URLs and less path leakage
(via `marimo._cli.cli.py._resolve_root_dir`)
- e.g. if I run `uv run marimo run
/Users/petergy/Projects/opensource/marimo-team/learn`. the `learn` repo
is recognized as gallery root, so opening
`/Users/petergy/Projects/opensource/marimo-team/learn/functional_programming/05_functors.py`
will be available under
`http://localhost:2720/?file=functional_programming%2F05_functors.py`
- Gallery entries have auto-generated `title` and `subtitle` for now
(notebook dir and file name piped through `titleCase`)

## TODO before undrafting this

- define `--sandbox` semantics
  - per-notebook or per-gallery venv?
- should we create sandbox eagerly (we create all the venvs at cmd
execution time) or lazily (create venv only on notebook visit)?

## 📋 Checklist

- [x] I have read the [contributor
guidelines](https://github.com/marimo-team/marimo/blob/main/CONTRIBUTING.md).
- [x] For large changes, or changes that affect the public API: this
change was discussed or approved through an issue, on
[Discord](https://marimo.io/discord?ref=pr), or the community
[discussions](https://github.com/marimo-team/marimo/discussions) (Please
provide a link if applicable).
- [x] Tests have been added for the changes made.
- [x] Documentation has been updated where applicable, including
docstrings for API changes.
- [x] Pull request title is a good summary of the changes - it will be
used in the [release
notes](https://github.com/marimo-team/marimo/releases).

---------

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

…ity (#8068)

## 📝 Summary

Currently weave tracing fails on the following code:

```python
chat_client = OpenAI()

@weave.op()
def handle_chat(messages, config):
    """Wrapper that ensures string return for marimo."""
    user_msg = messages[-1].content
    chat_messages = [{"role": "user", "content": user_msg}]

    response = chat_client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[get_system_prompt()] + chat_messages,
        tools=get_robot_tools(),
    )

    msg = response.choices[0].message
    return msg.content

chat = mo.ui.chat(
    handle_chat
)
chat
```

This is because `weave.op` returns a `BoxedStr(str)` which the causes
pydantic to fail. As such, we force a conversion to string even if
`isinstance(chunk, str)`.