Question about expected runtime behavior of bub-feishu scripts in sandboxed environments

[not94]

When bub-feishu is used from Codex, commands are commonly executed inside a sandboxed environment rather than a normal interactive shell. In that setup, shell-provided environment variables may not always be inherited as expected.

This seems to expose two related issues in the packaged Feishu scripts:

Configuration loading is not fully aligned with the main channel runtime. In sandboxed execution, feishu_send.py / feishu_edit.py may fail to read BUB_FEISHU_APP_ID and BUB_FEISHU_APP_SECRET even when the workspace is configured correctly. A possible solution would be to let the packaged scripts load configuration from a workspace .env file as well, for example via python-dotenv, so their behavior is more consistent with the rest of bub-feishu.

The packaged scripts also depend on runtime packages such as httpx. In practice this works when they are executed via uv run, but direct execution with plain python can fail if those dependencies are not installed in the host interpreter.

For the first issue, using .env loading seems like a reasonable improvement. For the second issue, I do not have a clearly better solution yet, so I would mainly like the maintainer’s opinion: should these packaged scripts be considered uv run-only, and should that execution model be documented more explicitly?

[PsiACE]

cc @specter119

[specter119]

For the first question, I would like to investigate further before drawing a firm conclusion. I have a similar usage pattern on my side, but I have not encountered this issue so far (at least as of a few days ago). It would be helpful to better understand the exact conditions under which the environment variables are not being picked up in the sandboxed setup.

For the second question, my current understanding is that these scripts follow the same execution model as other plugins, which implicitly assume that uv is available so that PEP 723-style inline dependencies can be resolved. In this context, the dependency on httpx is not fundamentally different from using requests—if a script relies on requests and the host interpreter does not have it installed, it would encounter the same issue when executed with plain python.

Based on this, it seems reasonable to consider uv as an implicit dependency for running these scripts reliably. Making this expectation more explicit in the documentation could help avoid confusion for users attempting to run them outside of a uv run environment.

[not94]

For the first question, I would like to investigate further before drawing a firm conclusion. I have a similar usage pattern on my side, but I have not encountered this issue so far (at least as of a few days ago). It would be helpful to better understand the exact conditions under which the environment variables are not being picked up in the sandboxed setup.

For the second question, my current understanding is that these scripts follow the same execution model as other plugins, which implicitly assume that uv is available so that PEP 723-style inline dependencies can be resolved. In this context, the dependency on httpx is not fundamentally different from using requests—if a script relies on requests and the host interpreter does not have it installed, it would encounter the same issue when executed with plain python.

Based on this, it seems reasonable to consider uv as an implicit dependency for running these scripts reliably. Making this expectation more explicit in the documentation could help avoid confusion for users attempting to run them outside of a uv run environment.

After a few more experiments, I found that the instability is mainly caused by Codex sandbox permissions plus global Codex config, not by the plugin logic itself.

The shell env policy needs to be set to inherit all variables (inherit = "all"), as documented here: Codex shell environment policy.
The sandbox needs workspace-write permission, because dependency/runtime handling (for example when httpx is missing) may require write access.
So in practice, running this plugin reliably currently seems to require Codex YOLO mode. If we want better control over execution permissions without fully switching to YOLO, it would help if Codex/plugin integration exposed more granular CLI permission options.