komodo-core and komodo-periphery running 2.0.0 docker image
Assume a debian:bookworm container is running on "my-server":
docker run --name debug -it debian:bookworm /bin/sh
I'm trying to execute a command on this container using an Action, specifically the execute_container_terminal method of the typescript client. Thus from the UI I create an action with this content:
letshell="sh";// sh or bash
letserver="my-server";letcontainer="debug";letcommand="date";awaitkomodo.execute_container_terminal({server,container,command,init:{command: shell,recreate:"Always"},},{onLine:(line)=>{console.log(line);},onFinish:(code)=>{console.log(`Command finished with exit code ${code}`);},},);
Expected behavior
Using bash or sh, executing the action succeeds and the following output is produced:
Sat Mar 28 20:31:22 UTC 2026
Command finished with exit code 0
🦎 Action completed successfully 🦎
Actual behavior
Sometimes the command is executed incorrectly, resulting in the following output:
Updated behavior from "succeeds with bash but fails with sh" to "randomly fails"
Originally created by @bastienlc on GitHub (Mar 28, 2026).
Original GitHub issue: https://github.com/moghtech/komodo/issues/1289
## Setting
*komodo-core and komodo-periphery running 2.0.0 docker image*
Assume a debian:bookworm container is running on "my-server":
```bash
docker run --name debug -it debian:bookworm /bin/sh
```
I'm trying to execute a command on this container using an Action, specifically the `execute_container_terminal` method of the typescript client. Thus from the UI I create an action with this content:
```ts
let shell = "sh"; // sh or bash
let server = "my-server";
let container = "debug";
let command = "date";
await komodo.execute_container_terminal(
{
server,
container,
command,
init: { command: shell, recreate: "Always" },
},
{
onLine: (line) => {
console.log(line);
},
onFinish: (code) => {
console.log(`Command finished with exit code ${code}`);
},
},
);
```
## Expected behavior
Using `bash` or `sh`, executing the action succeeds and the following output is produced:
```bash
Sat Mar 28 20:31:22 UTC 2026
Command finished with exit code 0
🦎 Action completed successfully 🦎
```
## Actual behavior
Sometimes the command is executed incorrectly, resulting in the following output:
```bash
'; date; rc=$?; printf '
Command finished with exit code %d
🦎 Action completed successfully 🦎
```
I have not been able to pinpoint exactly what causes this behavior to occur, currently it seems random.
## Initial analysis
While I'm not familiar with the komodo source code, the issue seems to stem from this snippet:
https://github.com/moghtech/komodo/blob/0f9679455911ce9f078e1d3654437ce4cda84eda/bin/periphery/src/api/terminal.rs#L466-L468
## Edits
- Updated behavior from "succeeds with bash but fails with sh" to "randomly fails"
My testing was done on stacks (komodo.execute_stack_exec), but same result.
<!-- gh-comment-id:4246440732 -->
@martkaczmarek commented on GitHub (Apr 14, 2026):
Happening to me too.
Komodo periphery + core both on Docker, 2.1.2
In my case, even multiple executes across a singe action could change behavior (this is output of a single action):
```
execute_stack_exec bash:
Tue Apr 14 19:07:41 UTC 2026 <--"date" command executed properly
Exit code: 0
execute_stack_exec sh:
'; date; rc=$?; printf ' <--"date" command printed as is
Exit code: %d
execute_stack_service_terminal bash:
'; date; rc=$?; printf '
Finished. Code: %d
execute_stack_service_terminal sh:
'; date; rc=$?; printf '
Finished. Code: %d
🦎 Action completed successfully 🦎
```
My testing was done on stacks (komodo.execute_stack_exec), but same result.
The terminal actually does execute the command and returns exit code:
(this is the terminal executing the same action run)
It looks to me like Komodo is just confused as to which __KOMODO_START_OF_OUTPUT__ to treat as the actual output text - it catches the first one and returns '; date; rc=$?; printf ' which is below.
--Edit after a bit more testing:
In my case, the first run in a specific terminal will result in a wrong output. But if the terminal is not recreated, the subsequent commands return proper text.
@bastienlc can you confirm that? If you change recreate value to "Never" and not delete the terminal, the second and all subsequent runs should be fine.
<!-- gh-comment-id:4246626525 -->
@martkaczmarek commented on GitHub (Apr 14, 2026):
I'd like to point out another thing:
even when output is wrong:
```
'; date; rc=$?; printf '
Exit code: %d
🦎 Action completed successfully 🦎
```
The terminal actually does execute the command and returns exit code:
<img width="472" height="494" alt="Image" src="https://github.com/user-attachments/assets/ed538918-96d6-489e-b1a6-1d054ac950b1" />
(this is the terminal executing the same action run)
It looks to me like Komodo is just confused as to which `__KOMODO_START_OF_OUTPUT__` to treat as the actual output text - it catches the first one and returns `'; date; rc=$?; printf '` which is below.
--Edit after a bit more testing:
In my case, the first run in a specific terminal will result in a wrong output. But if the terminal is **not** recreated, the subsequent commands return proper text.
@bastienlc can you confirm that? If you change recreate value to "Never" and not delete the terminal, the second and all subsequent runs should be fine.
I think it should usually work if the shell is "bash", but doesn't seem to with "sh"
<!-- gh-comment-id:4247801911 -->
@mbecker20 commented on GitHub (Apr 14, 2026):
I think it should usually work if the shell is "bash", but doesn't seem to with "sh"
@martkaczmarek I have not been able to reproduce your results:
On debian/ubuntu images
Using bash, execute_container_terminal works on the first try, and also on subsequent tries when setting recreate: "Never"
Using sh, execute_container_terminal never works, not on the first try, and not on subsequent tries when setting recreate: "Never"
On alpine images
Using bash is not an option
Using sh, execute_container_terminal works on the first try, and also on subsequent tries when setting recreate: "Never"
Analysis
What I'm observing today corresponds to my initial assessment "succeeds with bash but fails with sh" on debian images. However I believe there is more to this issue, as I am seeing occasional failures with the same output when using bash:
In <1% of cases on an amd64 server
In a very significant number of cases on an arm64 server, with an unpredictable pattern (each X is a faillure on an action that runs every 5 minutes):
But I'm unable to consistently reproduce these failures.
However I agree that this is a parsing issue of the terminal output, and the command is executed correctly. It still breaks functionality e.g. when using actions in procedures, the action errors out and the procedure fails.
<!-- gh-comment-id:4255287237 -->
@bastienlc commented on GitHub (Apr 15, 2026):
@martkaczmarek I have not been able to reproduce your results:
#### On debian/ubuntu images
- Using bash, `execute_container_terminal` works on the first try, and also on subsequent tries when setting `recreate: "Never"`
- Using sh, `execute_container_terminal` never works, not on the first try, and not on subsequent tries when setting `recreate: "Never"`
#### On alpine images
- Using bash is not an option
- Using sh, `execute_container_terminal` works on the first try, and also on subsequent tries when setting `recreate: "Never"`
### Analysis
What I'm observing today corresponds to my initial assessment "succeeds with bash but fails with sh" on debian images. However I believe there is more to this issue, as I am seeing occasional failures with the same output when using bash:
- In <1% of cases on an amd64 server
- In a very significant number of cases on an arm64 server, with an unpredictable pattern (each X is a faillure on an action that runs every 5 minutes):
```
OOOOXOXOOXXOOOOOXXOOOXOXOOXOXOOXOOOOOXOOOOXOOOOXXOXOXOOOXOOOXXOXOXXXXOXXXXXXXXOXOOXXOOOOOOOOOOOOOOO
```
But I'm unable to consistently reproduce these failures.
However I agree that this is a parsing issue of the terminal output, and the command is executed correctly. It still breaks functionality e.g. when using actions in procedures, the action errors out and the procedure fails.
1.6 KB script with the same shape but only 5 small writes: consistently "%d".
Adding ~6 KB of no-op chunked work (printf %s '<1 KB base64>' | base64 -d > /dev/null × 6) before the trailing echo flips it back to "0".
onLine callbacks also receive nothing on these runs (regardless of which bucket). Suggests the bug is in how the wrapper output is read/parsed before the marker substitution can complete for short scripts.
<!-- gh-comment-id:4847092481 -->
@andyrue commented on GitHub (Jun 30, 2026):
Hitting this with `execute_server_terminal` as well. In our case it's strongly correlated with script size, not random:
- Bare `echo HELLO` via `execute_server_terminal`: `onFinish` consistently receives `"%d"`.
- ~12 KB script (chunked `printf | base64 -d` × ~25): consistently receives `"0"`.
- 1.6 KB script with the same shape but only 5 small writes: consistently `"%d"`.
- Adding ~6 KB of no-op chunked work (`printf %s '<1 KB base64>' | base64 -d > /dev/null` × 6) before the trailing `echo` flips it back to `"0"`.
`onLine` callbacks also receive nothing on these runs (regardless of which bucket). Suggests the bug is in how the wrapper output is read/parsed before the marker substitution can complete for short scripts.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @bastienlc on GitHub (Mar 28, 2026).
Original GitHub issue: https://github.com/moghtech/komodo/issues/1289
Setting
komodo-core and komodo-periphery running 2.0.0 docker image
Assume a debian:bookworm container is running on "my-server":
I'm trying to execute a command on this container using an Action, specifically the
execute_container_terminalmethod of the typescript client. Thus from the UI I create an action with this content:Expected behavior
Using
bashorsh, executing the action succeeds and the following output is produced:Actual behavior
Sometimes the command is executed incorrectly, resulting in the following output:
I have not been able to pinpoint exactly what causes this behavior to occur, currently it seems random.
Initial analysis
While I'm not familiar with the komodo source code, the issue seems to stem from this snippet:
https://github.com/moghtech/komodo/blob/0f9679455911ce9f078e1d3654437ce4cda84eda/bin/periphery/src/api/terminal.rs#L466-L468
Edits
@martkaczmarek commented on GitHub (Apr 14, 2026):
Happening to me too.
Komodo periphery + core both on Docker, 2.1.2
In my case, even multiple executes across a singe action could change behavior (this is output of a single action):
My testing was done on stacks (komodo.execute_stack_exec), but same result.
@martkaczmarek commented on GitHub (Apr 14, 2026):
I'd like to point out another thing:
even when output is wrong:
The terminal actually does execute the command and returns exit code:
(this is the terminal executing the same action run)
It looks to me like Komodo is just confused as to which
__KOMODO_START_OF_OUTPUT__to treat as the actual output text - it catches the first one and returns'; date; rc=$?; printf 'which is below.--Edit after a bit more testing:
In my case, the first run in a specific terminal will result in a wrong output. But if the terminal is not recreated, the subsequent commands return proper text.
@bastienlc can you confirm that? If you change recreate value to "Never" and not delete the terminal, the second and all subsequent runs should be fine.
@mbecker20 commented on GitHub (Apr 14, 2026):
I think it should usually work if the shell is "bash", but doesn't seem to with "sh"
@bastienlc commented on GitHub (Apr 15, 2026):
@martkaczmarek I have not been able to reproduce your results:
On debian/ubuntu images
execute_container_terminalworks on the first try, and also on subsequent tries when settingrecreate: "Never"execute_container_terminalnever works, not on the first try, and not on subsequent tries when settingrecreate: "Never"On alpine images
execute_container_terminalworks on the first try, and also on subsequent tries when settingrecreate: "Never"Analysis
What I'm observing today corresponds to my initial assessment "succeeds with bash but fails with sh" on debian images. However I believe there is more to this issue, as I am seeing occasional failures with the same output when using bash:
But I'm unable to consistently reproduce these failures.
However I agree that this is a parsing issue of the terminal output, and the command is executed correctly. It still breaks functionality e.g. when using actions in procedures, the action errors out and the procedure fails.
@andyrue commented on GitHub (Jun 30, 2026):
Hitting this with
execute_server_terminalas well. In our case it's strongly correlated with script size, not random:echo HELLOviaexecute_server_terminal:onFinishconsistently receives"%d".printf | base64 -d× ~25): consistently receives"0"."%d".printf %s '<1 KB base64>' | base64 -d > /dev/null× 6) before the trailingechoflips it back to"0".onLinecallbacks also receive nothing on these runs (regardless of which bucket). Suggests the bug is in how the wrapper output is read/parsed before the marker substitution can complete for short scripts.